On 01/13/2014 01:47 PM, Les Mikesell wrote: > 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. > Of course, we need to TRY to make it so that things from (2) "tier 3" can be used together on the same machines. How we might be able to that is one question. Some we might not be able to work together, but in general it should be a goal htat they do. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20140114/b8d2796a/attachment-0005.sig>