On Wed, Jan 15, 2014 at 12:16 PM, Karanbir Singh <mail-lists at karan.org> wrote: > >> I'd give a lot of credit for the popularity of Ubuntu to their more >> sane handling of 3rd party packages. Even the ones they don't host >> directly are generally available from a repository that is easily >> enabled (without hunting for it, or guessing which ones will break >> your system), and generally coordinated to avoid conflicts. > > if someone can : > > - define what 'breaks your system is' I don't think that is possible in the broad sense - it could be as subtle as a package being configured to listen on the same port as an existing service uses. The obvious things are having same-named packages with different contents or same-named files owned by different packages. > - write code that can test for 'breaks' How do you test the package contents of unknown 3rd party repos against your own? And in an update you expect the contents to change anyway. I don't know if it is still true, but at least at some time in the past EPEL and RPMFORGE both had 'viewvc' packages with incompatible configurations. Whenever one would bump its version number it would update and the one from the alternate repo would be misconfigured. I think I got into that state because EPEL didn't have the package initially but added it after I had installed from RPMFORGE. Some of those problems could be avoided if yum only considered updates from the repo that provided it in the first place unless you do something to tell it to switch. > we can plumb that into the CI / nightly / pre-release testing to make > sure that we can atleast notify the right people in time; ideally > building upto proper coordination. I think you should make the assumption that everyone will have EPEL enabled. So every package added to EPEL creates potential new conflicts with every other 3rd party. And since EPEL has restrictions on what they will accept, many people will need to use other 3rd party repos. > if you cant automate this, then its an education process. Feel free to > start write docs and policies, then educating people around it - > Fedora's knowldge base is a good place to start from I don't think it is possible/practical for you to test against the contents of all 3rd party repos. Is there a way to reverse the concept and make it easier for the people maintaining the repos of content that you - and EPEL - won't accept to test for conflicts without being strictly coordinated? And what would you suggest as the 'right' way to handle a conflict created when EPEL adds a package that breaks one that had previously been available elsewhere, like the viewvc example above? This isn't strictly a CentOS problem, but it is a problem that CentOS users have to deal with (and RHEL users, although there probably aren't many people paying for RHEL support to build a home media player...) -- Les Mikesell lesmikesell at gmail.com