hi,
We are going to need to find a way to address content in CentOS ( or well, content in EPEL ) where there are packages in centos that didnt come from rhel but are going to overlap with whats in EPEL.
Technically, this is a centos.org issue since EPEL's mandate requires them to not overlap with RHEL[1]. But with stuff going into CentOS-Extras/ and more content coming onboard from SIG's - and even from Core SIG - how are we going to address the overlap / flapping potential with EPEL ?
I am going to be pulling in cloud-init with a couple of deps, need to have these in the centos.org repos to do cloud instance builds.
- KB
[1]: I am not sure if EPEL cant overlap with base RHEL or with variants and layered products ?
On Wed, Jul 9, 2014 at 3:37 AM, Karanbir Singh mail-lists@karan.org wrote:
hi,
We are going to need to find a way to address content in CentOS ( or well, content in EPEL ) where there are packages in centos that didnt come from rhel but are going to overlap with whats in EPEL.
Technically, this is a centos.org issue since EPEL's mandate requires them to not overlap with RHEL[1]. But with stuff going into CentOS-Extras/ and more content coming onboard from SIG's - and even from Core SIG - how are we going to address the overlap / flapping potential with EPEL ?
I am going to be pulling in cloud-init with a couple of deps, need to have these in the centos.org repos to do cloud instance builds.
- KB
[1]: I am not sure if EPEL cant overlap with base RHEL or with variants and layered products ?
EPEL is historically exremely cautios *not* to overlap with RHEL, and thus with basic CentOS. extras..... is another issue.
2014-07-09 10:29 GMT+02:00 Nico Kadel-Garcia nkadel@gmail.com:
On Wed, Jul 9, 2014 at 3:37 AM, Karanbir Singh mail-lists@karan.org wrote:
hi,
We are going to need to find a way to address content in CentOS ( or well, content in EPEL ) where there are packages in centos that didnt come from rhel but are going to overlap with whats in EPEL.
Technically, this is a centos.org issue since EPEL's mandate requires them to not overlap with RHEL[1]. But with stuff going into CentOS-Extras/ and more content coming onboard from SIG's - and even from Core SIG - how are we going to address the overlap / flapping potential with EPEL ?
I am going to be pulling in cloud-init with a couple of deps, need to have these in the centos.org repos to do cloud instance builds.
- KB
[1]: I am not sure if EPEL cant overlap with base RHEL or with variants and layered products ?
EPEL is historically exremely cautios *not* to overlap with RHEL, and thus with basic CentOS. extras..... is another issue.
That's right. In my opinion, this is a CentOS issue. Fedora EPEL is not only for CentOS. Fedora EPEL packages are also for other RHEL clones like Scientific Linux or Oracle Linux.
Best regards,
Morten
On 07/09/2014 02:37 AM, Karanbir Singh wrote:
hi,
We are going to need to find a way to address content in CentOS ( or well, content in EPEL ) where there are packages in centos that didnt come from rhel but are going to overlap with whats in EPEL.
Technically, this is a centos.org issue since EPEL's mandate requires them to not overlap with RHEL[1]. But with stuff going into CentOS-Extras/ and more content coming onboard from SIG's - and even from Core SIG - how are we going to address the overlap / flapping potential with EPEL ?
I am going to be pulling in cloud-init with a couple of deps, need to have these in the centos.org repos to do cloud instance builds.
- KB
[1]: I am not sure if EPEL cant overlap with base RHEL or with variants and layered products ?
The only real way to handle it is with excludes or priorities in the yum config files .. that, or some other thing like epochs or higher versions in the centos.org content to make it newer (assuming that is the goal).
This will cause issues though, that will will need to work to fix and provide instructions for in an FAQ, etc ... when they arise.
On 07/09/2014 12:24 PM, Johnny Hughes wrote:
On 07/09/2014 02:37 AM, Karanbir Singh wrote:
hi,
We are going to need to find a way to address content in CentOS ( or well, content in EPEL ) where there are packages in centos that didnt come from rhel but are going to overlap with whats in EPEL.
Technically, this is a centos.org issue since EPEL's mandate requires them to not overlap with RHEL[1]. But with stuff going into CentOS-Extras/ and more content coming onboard from SIG's - and even from Core SIG - how are we going to address the overlap / flapping potential with EPEL ?
I am going to be pulling in cloud-init with a couple of deps, need to have these in the centos.org repos to do cloud instance builds.
- KB
[1]: I am not sure if EPEL cant overlap with base RHEL or with variants and layered products ?
The only real way to handle it is with excludes or priorities in the yum config files .. that, or some other thing like epochs or higher versions in the centos.org content to make it newer (assuming that is the goal).
I am hoping we can find a way to communicate this and sync with the epel folks in a manner that it does not cause too much issues. priorities will help i guess, but it will cause issues when people want to consume one and not the other ( either way ), specially when its down to libs
On 07/09/2014 03:14 PM, Karanbir Singh wrote:
On 07/09/2014 12:24 PM, Johnny Hughes wrote:
On 07/09/2014 02:37 AM, Karanbir Singh wrote:
hi,
We are going to need to find a way to address content in CentOS ( or well, content in EPEL ) where there are packages in centos that didnt come from rhel but are going to overlap with whats in EPEL.
Technically, this is a centos.org issue since EPEL's mandate requires them to not overlap with RHEL[1]. But with stuff going into CentOS-Extras/ and more content coming onboard from SIG's - and even from Core SIG - how are we going to address the overlap / flapping potential with EPEL ?
I am going to be pulling in cloud-init with a couple of deps, need to have these in the centos.org repos to do cloud instance builds.
- KB
[1]: I am not sure if EPEL cant overlap with base RHEL or with variants and layered products ?
The only real way to handle it is with excludes or priorities in the yum config files .. that, or some other thing like epochs or higher versions in the centos.org content to make it newer (assuming that is the goal).
I am hoping we can find a way to communicate this and sync with the epel folks in a manner that it does not cause too much issues. priorities will help i guess, but it will cause issues when people want to consume one and not the other ( either way ), specially when its down to libs
Can;t we go with a new/separate repo , default disabled, with different (higher) priority ?
On 07/09/2014 01:19 PM, Manuel Wolfshant wrote:
On 07/09/2014 03:14 PM, Karanbir Singh wrote:
On 07/09/2014 12:24 PM, Johnny Hughes wrote:
On 07/09/2014 02:37 AM, Karanbir Singh wrote:
hi,
We are going to need to find a way to address content in CentOS ( or well, content in EPEL ) where there are packages in centos that didnt come from rhel but are going to overlap with whats in EPEL.
Technically, this is a centos.org issue since EPEL's mandate requires them to not overlap with RHEL[1]. But with stuff going into CentOS-Extras/ and more content coming onboard from SIG's - and even from Core SIG - how are we going to address the overlap / flapping potential with EPEL ?
I am going to be pulling in cloud-init with a couple of deps, need to have these in the centos.org repos to do cloud instance builds.
- KB
[1]: I am not sure if EPEL cant overlap with base RHEL or with variants and layered products ?
The only real way to handle it is with excludes or priorities in the yum config files .. that, or some other thing like epochs or higher versions in the centos.org content to make it newer (assuming that is the goal).
I am hoping we can find a way to communicate this and sync with the epel folks in a manner that it does not cause too much issues. priorities will help i guess, but it will cause issues when people want to consume one and not the other ( either way ), specially when its down to libs
Can;t we go with a new/separate repo , default disabled, with different (higher) priority ?
if we disable extras, we've cut off epel completely. Also sig's and other efforts wont want to ship orhpahed code, so they will want their own content to always be visible.
On 07/09/2014 04:52 PM, Karanbir Singh wrote:
On 07/09/2014 01:19 PM, Manuel Wolfshant wrote:
On 07/09/2014 03:14 PM, Karanbir Singh wrote:
On 07/09/2014 12:24 PM, Johnny Hughes wrote:
On 07/09/2014 02:37 AM, Karanbir Singh wrote:
hi,
We are going to need to find a way to address content in CentOS ( or well, content in EPEL ) where there are packages in centos that didnt come from rhel but are going to overlap with whats in EPEL.
Technically, this is a centos.org issue since EPEL's mandate requires them to not overlap with RHEL[1]. But with stuff going into CentOS-Extras/ and more content coming onboard from SIG's - and even from Core SIG - how are we going to address the overlap / flapping potential with EPEL ?
I am going to be pulling in cloud-init with a couple of deps, need to have these in the centos.org repos to do cloud instance builds.
- KB
[1]: I am not sure if EPEL cant overlap with base RHEL or with variants and layered products ?
The only real way to handle it is with excludes or priorities in the yum config files .. that, or some other thing like epochs or higher versions in the centos.org content to make it newer (assuming that is the goal).
I am hoping we can find a way to communicate this and sync with the epel folks in a manner that it does not cause too much issues. priorities will help i guess, but it will cause issues when people want to consume one and not the other ( either way ), specially when its down to libs
Can;t we go with a new/separate repo , default disabled, with different (higher) priority ?
if we disable extras, we've cut off epel completely. Also sig's and other efforts wont want to ship orhpahed code, so they will want their own content to always be visible.
I explicitely mentioned a *separate* repo. The idea of keeping it default disabled was in sync with shipping the [repo] config for it in centos-release, but if we ship in extras a newrepo-release.rpm for it, we can leave it enabled as it should get installed only by those needing it.
On Wed, Jul 9, 2014 at 7:19 AM, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
The only real way to handle it is with excludes or priorities in the yum config files .. that, or some other thing like epochs or higher versions in the centos.org content to make it newer (assuming that is the goal).
I am hoping we can find a way to communicate this and sync with the epel folks in a manner that it does not cause too much issues. priorities will help i guess, but it will cause issues when people want to consume one and not the other ( either way ), specially when its down to libs
Can;t we go with a new/separate repo , default disabled, with different (higher) priority ?
It's not that simple. The historic problem with EPEL is that when you want a package they don't initially have it. So you get it from some other 3rd party repo. Then EPEL adds it. At that point there is no 'right' answer to the question of which one you want. It may subsequently be better-maintained in EPEL, but the switch may not be transparent (different configs/build options, etc.). Or the EPEL version may be crippled by restrictions on code that can be distributed in the US or have build options that don't meet your needs. I don't think a default priority can make this choice correctly.
On Wed, Jul 09, 2014 at 01:14:27PM +0100, Karanbir Singh wrote:
I am hoping we can find a way to communicate this and sync with the epel folks in a manner that it does not cause too much issues. priorities will help i guess, but it will cause issues when people want to consume one and not the other ( either way ), specially when its down to libs
It's getting a bit late, but there is a session on the future of EPEL at Flock in Prague next month: http://sched.co/SbXE17 -- it'd be great to have interested CentOS people there.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/09/2014 07:59 AM, Matthew Miller wrote:
On Wed, Jul 09, 2014 at 01:14:27PM +0100, Karanbir Singh wrote:
I am hoping we can find a way to communicate this and sync with the epel folks in a manner that it does not cause too much issues. priorities will help i guess, but it will cause issues when people want to consume one and not the other ( either way ), specially when its down to libs
It's getting a bit late, but there is a session on the future of EPEL at Flock in Prague next month: http://sched.co/SbXE17 -- it'd be great to have interested CentOS people there.
As it happens, we've got a bunch of the core team planning to attend specifically to work on future-proofing discussions with Fedora.
Is anyone else planning on going?
- -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
On Wed, Jul 9, 2014 at 9:37 AM, Karsten Wade kwade@redhat.com wrote:
It's getting a bit late, but there is a session on the future of EPEL at Flock in Prague next month: http://sched.co/SbXE17 -- it'd be great to have interested CentOS people there.
As it happens, we've got a bunch of the core team planning to attend specifically to work on future-proofing discussions with Fedora.
Is anyone else planning on going?
I would love to participate but don't think I can make it to Prague next month...
-Jeff
On 9 July 2014 08:59, Matthew Miller mattdm@mattdm.org wrote:
On Wed, Jul 09, 2014 at 01:14:27PM +0100, Karanbir Singh wrote:
I am hoping we can find a way to communicate this and sync with the epel folks in a manner that it does not cause too much issues. priorities will help i guess, but it will cause issues when people want to consume one and not the other ( either way ), specially when its down to libs
It's getting a bit late, but there is a session on the future of EPEL at Flock in Prague next month: http://sched.co/SbXE17 -- it'd be great to have interested CentOS people there.
I would like to make sure that the CentOS partnership with Red Hat is part of the EPEL discussion. I need to put out an email on this later today.
On Wed, Jul 9, 2014 at 7:24 AM, Johnny Hughes johnny@centos.org wrote:
On 07/09/2014 02:37 AM, Karanbir Singh wrote:
hi,
We are going to need to find a way to address content in CentOS ( or well, content in EPEL ) where there are packages in centos that didnt come from rhel but are going to overlap with whats in EPEL.
Technically, this is a centos.org issue since EPEL's mandate requires them to not overlap with RHEL[1]. But with stuff going into CentOS-Extras/ and more content coming onboard from SIG's - and even from Core SIG - how are we going to address the overlap / flapping potential with EPEL ?
I am going to be pulling in cloud-init with a couple of deps, need to have these in the centos.org repos to do cloud instance builds.
- KB
[1]: I am not sure if EPEL cant overlap with base RHEL or with variants and layered products ?
The only real way to handle it is with excludes or priorities in the yum config files .. that, or some other thing like epochs or higher versions in the centos.org content to make it newer (assuming that is the goal).
This will cause issues though, that will will need to work to fix and provide instructions for in an FAQ, etc ... when they arise.
One approach, used by Red Hat themselves, is to put a minor version number or insert the vendor name in the package name itself, such as 'samba4' or the various java packages and openssl packages. And meta packaging has been used effectively for years for Java and SMTP servers and web servers.
It's not always applicable, especially of both repositories independently provide the same package. It also causes issues when one repository uses differently organized packaging for the *same* software, such as has been occurring with nagios-plugins on EPEL and Repoforge for years, and it's an ongoing reason to apply 3rd party repositories only as needed to a stable server, and with specific targeted packages.
Comments that are not just in a FAQ, but also in the /etc/yum.repos.d/*.repo files themselves for known conflicts might be particularly useful. If EPEL is going to continue using CentOS by default for 'mock', software building, it certainly makes sense to collaborate in keeping the tools compatible, and they seem nice folks.
On Jul 09 08:37, Karanbir Singh wrote:
hi,
We are going to need to find a way to address content in CentOS ( or well, content in EPEL ) where there are packages in centos that didnt come from rhel but are going to overlap with whats in EPEL.
Technically, this is a centos.org issue since EPEL's mandate requires them to not overlap with RHEL[1]. But with stuff going into CentOS-Extras/ and more content coming onboard from SIG's - and even from Core SIG - how are we going to address the overlap / flapping potential with EPEL ?
I am going to be pulling in cloud-init with a couple of deps, need to have these in the centos.org repos to do cloud instance builds.
- KB
[1]: I am not sure if EPEL cant overlap with base RHEL or with variants and layered products ?
-- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc
Will there be a "review" process for conflicting packages? I was thinking we could gather some epel "liasons" who are well-versed in the EPEL policies who can provide advice to new SIG developers. That way we also have a record of what conflicts. Of course this doesn't solve the actual technical problem at hand :)
Brian
-- Brian Stinson bstinson@ksu.edu | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk
On 07/09/2014 03:08 PM, Brian Stinson wrote:
Will there be a "review" process for conflicting packages? I was thinking we could gather some epel "liasons" who are well-versed in the EPEL policies who can provide advice to new SIG developers. That way we also have a record of what conflicts. Of course this doesn't solve the actual technical problem at hand :)
That would work,
how/when/where would this sort of a filter run. Maye at the push-to-prod state ? a nightly run on all devel and test builds ?
- KB
On Jul 09 15:18, Karanbir Singh wrote:
On 07/09/2014 03:08 PM, Brian Stinson wrote:
Will there be a "review" process for conflicting packages? I was thinking we could gather some epel "liasons" who are well-versed in the EPEL policies who can provide advice to new SIG developers. That way we also have a record of what conflicts. Of course this doesn't solve the actual technical problem at hand :)
That would work,
how/when/where would this sort of a filter run. Maye at the push-to-prod state ? a nightly run on all devel and test builds ?
- KB
-- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc
I'm not overly familiar with the internals of koji, but perhaps we could look through build logs before raising the gate on a release? I'm happy to help dig into building some tools with someone more experienced if that's what we need.
Brian
-- Brian Stinson bstinson@ksu.edu | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09.07.2014 09:37, Karanbir Singh wrote:
hi,
We are going to need to find a way to address content in CentOS ( or well, content in EPEL ) where there are packages in centos that didnt come from rhel but are going to overlap with whats in EPEL.
Technically, this is a centos.org issue since EPEL's mandate requires them to not overlap with RHEL[1]. But with stuff going into CentOS-Extras/ and more content coming onboard from SIG's - and even from Core SIG - how are we going to address the overlap / flapping potential with EPEL ?
I honestly think each sig should sort their issues out themselves. reasoning with example: As a matter of fact you can easily create sig a and sig b where sig a wants package x from base repo and sig b wants package x from epel -> you can't make both happy -> they need to make themselves happy by specifying their own repo structure or package pinning and which package comes from which repo. projects like ovirt already do this on EL6 with some third party repos for gluster, epel etc.
I am going to be pulling in cloud-init with a couple of deps, need to have these in the centos.org repos to do cloud instance builds.
where do you pull cloud-init in? in base or in a non-core sig? cloud-init was in epel for el6 if I remember correctly. I don't see it in "base" for the core sig, it could still reside in epel. the cloud sig might choose to define their own extra cloud repo on top and prefer maybe a newer cloud-init from their cloud-repo over the version in epel. (I haven't checked versions, this is just a made up example).
As for the "core" sig which might conflict with epel:
should there really be any conflicts? Is there a list of conflicting packages somewhere?
I can imagine this for i686 builds as they are not provided by upstream, but for the plain core?
On Wed, Jul 9, 2014 at 11:41 AM, Sven Kieske svenkieske@gmail.com wrote:
Technically, this is a centos.org issue since EPEL's mandate requires them to not overlap with RHEL[1]. But with stuff going into CentOS-Extras/ and more content coming onboard from SIG's - and even from Core SIG - how are we going to address the overlap / flapping potential with EPEL ?
I honestly think each sig should sort their issues out themselves. reasoning with example:
How do you suggest handling the likely scenario where a SIG adds a new package not currently in EPEL and subsequently EPEL adds that same package but with different contents/options/versions?
Or a package in EPEL that a SIG user needs or may add includes the same file as a SIG package, creating a conflict? Again, this may change after releases and block updates when there is no coordination among the repositories.
These have been common issues, pretty much forever for people using packages from multiple repositories. I'm not convinced there is a generic solution that doesn't involve tracking all of the files and dependencies across all of the repositories just like you have to within a single one.
On 07/09/2014 07:04 PM, Les Mikesell wrote:
On Wed, Jul 9, 2014 at 11:41 AM, Sven Kieske svenkieske@gmail.com wrote:
Technically, this is a centos.org issue since EPEL's mandate requires them to not overlap with RHEL[1]. But with stuff going into CentOS-Extras/ and more content coming onboard from SIG's - and even from Core SIG - how are we going to address the overlap / flapping potential with EPEL ?
I honestly think each sig should sort their issues out themselves. reasoning with example:
How do you suggest handling the likely scenario where a SIG adds a new package not currently in EPEL and subsequently EPEL adds that same package but with different contents/options/versions?
Or a package in EPEL that a SIG user needs or may add includes the same file as a SIG package, creating a conflict? Again, this may change after releases and block updates when there is no coordination among the repositories.
These have been common issues, pretty much forever for people using packages from multiple repositories. I'm not convinced there is a generic solution that doesn't involve tracking all of the files and dependencies across all of the repositories just like you have to within a single one.
I have already suggested entire yum-plugin-priorities structure in this thread: http://lists.centos.org/pipermail/centos-devel/2014-January/009372.html
and here: http://lists.centos.org/pipermail/centos-devel/2014-January/009520.html
And I created/explained repository hierarchy here: http://lists.centos.org/pipermail/centos-devel/2014-January/009595.html
I am willing to further explain/expand on what I propose, so it is understood as best as possible.
On Sat, Jul 19, 2014 at 12:46:25PM +0200, Ljubomir Ljubojevic wrote:
On 07/09/2014 07:04 PM, Les Mikesell wrote:
On Wed, Jul 9, 2014 at 11:41 AM, Sven Kieske svenkieske@gmail.com wrote:
Technically, this is a centos.org issue since EPEL's mandate requires them to not overlap with RHEL[1]. But with stuff going into CentOS-Extras/ and more content coming onboard from SIG's - and even from Core SIG - how are we going to address the overlap / flapping potential with EPEL ?
I honestly think each sig should sort their issues out themselves. reasoning with example:
How do you suggest handling the likely scenario where a SIG adds a new package not currently in EPEL and subsequently EPEL adds that same package but with different contents/options/versions?
Or a package in EPEL that a SIG user needs or may add includes the same file as a SIG package, creating a conflict? Again, this may change after releases and block updates when there is no coordination among the repositories.
These have been common issues, pretty much forever for people using packages from multiple repositories. I'm not convinced there is a generic solution that doesn't involve tracking all of the files and dependencies across all of the repositories just like you have to within a single one.
I have already suggested entire yum-plugin-priorities structure in this thread: http://lists.centos.org/pipermail/centos-devel/2014-January/009372.html
and here: http://lists.centos.org/pipermail/centos-devel/2014-January/009520.html
And I created/explained repository hierarchy here: http://lists.centos.org/pipermail/centos-devel/2014-January/009595.html
I am willing to further explain/expand on what I propose, so it is understood as best as possible.
I've always thought, too, that priorities should be set up by default, and the defaults should be to protect the Centos* repos. I always set it up myself, giving centos* repos the lowest numbers and working up from there in the order of which things I don't want overwritten by other repos of lower priority. I usually give the Centos* repos a priority of ten, epel 20, and so forth, on the theory that in the *normal* case, I dont' want 3rd-party repos overriding the distro's own repos. I realize there are some cases where that isn't true, though.
I see your suggested priorities put epel and some others before the distro's own repos. I guess you have a good reason for that...
Fred
On 07/19/2014 03:26 PM, Fred Smith wrote:
On Sat, Jul 19, 2014 at 12:46:25PM +0200, Ljubomir Ljubojevic wrote:
On 07/09/2014 07:04 PM, Les Mikesell wrote:
On Wed, Jul 9, 2014 at 11:41 AM, Sven Kieske svenkieske@gmail.com wrote:
Technically, this is a centos.org issue since EPEL's mandate requires them to not overlap with RHEL[1]. But with stuff going into CentOS-Extras/ and more content coming onboard from SIG's - and even from Core SIG - how are we going to address the overlap / flapping potential with EPEL ?
I honestly think each sig should sort their issues out themselves. reasoning with example:
How do you suggest handling the likely scenario where a SIG adds a new package not currently in EPEL and subsequently EPEL adds that same package but with different contents/options/versions?
Or a package in EPEL that a SIG user needs or may add includes the same file as a SIG package, creating a conflict? Again, this may change after releases and block updates when there is no coordination among the repositories.
These have been common issues, pretty much forever for people using packages from multiple repositories. I'm not convinced there is a generic solution that doesn't involve tracking all of the files and dependencies across all of the repositories just like you have to within a single one.
I have already suggested entire yum-plugin-priorities structure in this thread: http://lists.centos.org/pipermail/centos-devel/2014-January/009372.html
and here: http://lists.centos.org/pipermail/centos-devel/2014-January/009520.html
And I created/explained repository hierarchy here: http://lists.centos.org/pipermail/centos-devel/2014-January/009595.html
I am willing to further explain/expand on what I propose, so it is understood as best as possible.
I've always thought, too, that priorities should be set up by default, and the defaults should be to protect the Centos* repos. I always set it up myself, giving centos* repos the lowest numbers and working up from there in the order of which things I don't want overwritten by other repos of lower priority. I usually give the Centos* repos a priority of ten, epel 20, and so forth, on the theory that in the *normal* case, I dont' want 3rd-party repos overriding the distro's own repos. I realize there are some cases where that isn't true, though.
I see your suggested priorities put epel and some others before the distro's own repos. I guess you have a good reason for that...
Fred
I would, for starters, change default priority for repo without priority set to for example 50.
Maybe even get RHEL to change that. repo configs that do not use priorities will not be affected, and those who do already have set all repos with priorities and they also will not be affected.
Then you set CentOS base and updates repos to 30 so every noncomplying repo has lower priority then main repositories, and then SiG's and 3rd party repos can introduce changes and set priority, probably even create consensus with them to gradate all 3rd party repos in common agreement of all 3ed party developers.
yum-plugin-priorities can be dependancy of epel-release, or centOS -Extras release, or SiG releases, so that default core distro without 3rd party repos does not have to be affected.
-
Brian Stinson -
Fred Smith -
Jeff Sheltren -
Johnny Hughes -
Karanbir Singh -
Karsten Wade -
Les Mikesell -
Ljubomir Ljubojevic -
Manuel Wolfshant -
Matthew Miller -
Morten Stevens -
Nico Kadel-Garcia -
Stephen John Smoogen -
Sven Kieske