[CentOS-devel] Repository structures for SIG and variants in the future

[Les Mikesell]

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