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

Mon Jan 13 19:47:40 UTC 2014
Les Mikesell <lesmikesell at gmail.com>

On Mon, Jan 13, 2014 at 1:32 PM, Sam Kottler <s at shk.io> wrote:
>> This would not be permitted. A tier 2 could rely on a tier 1, but a tier
>> 1 would not be allowed to rely on a tier 2. Apologies if I wasn't clear
>> about that. I probably could have worded it better.
> I see, so packages can only rely on packages that fall below their tier.

I'd expect lots of things to depend on EPEL.  And at the same time
offering packages that might eventually be added to EPEL.

>> I like this approach, but how would you propose resolving two SIGs with
>> conflicting patch requirements?
> Generally it seems like the 'work upstream to fix it' approach would
> work in this case, too. As for patches that are mutually exclusive I
> don't have any real insight; I'm sure others have approaches that work
> well to solve the problem, though. That being said I think it's actually
> fairly rare for two patches to be mutually exclusive in tier 1 or 2.

I think you are being optimistic, if you consider that you aren't
starting from scratch.  I'd guess that there would be a bunch of
conflicts in terms of same-named packages with differences  or
different packages with same-named files across
ClearOS/SME/Nethserver.   And maybe even contents that don't conflict
during install but have subtle differences that will break if you have
the wrong one.   Maybe these things can be worked out before putting
them in a layout where mismatching components is easy, though.

> Maybe tier 3 should have a different policy around duplication across
> SIG's than the lower two?

Assuming that all of these repos will be forced to have the same
policies about allowed content as EPEL, the nicest thing to do would
be to push as much as possible into EPEL with the specialized versions
just managing configuration options.   And that leaves us with the
additional problem of needing uncoordinated repos to contain packages
that EPEL won't accept.

   Les Mikesell
     lesmikesell at gmail.com