Hi all!
The maintainer of the package "trousers" asked the epel-signers to pull that package from the EPEL repos as it's in EL since 5.2 now. I would have simply done it, but it turned out that the EVR in EPEL is higher then the one in EL:
$ sudo yum list trousers trousers.x86_64 0.3.1-5.el5 epel
trousers.i386 0.3.1-5.el5 epel $ sudo yum list trousers --disablerepo=epel trousers.i386 0.3.1-4.el5 rhel-x86_64-serv trousers.x86_64 0.3.1-4.el5 rhel-x86_64-serv
So what do do? I tend a bit to say "remove it as long as the RHEL maintainer promises to ship the next updates with a release of '6' or higher". But that has downsides as well :-/ .
Comments?
CU knurd
On Sat, Aug 2, 2008 at 7:19 AM, Thorsten Leemhuis fedora@leemhuis.info wrote:
Hi all!
The maintainer of the package "trousers" asked the epel-signers to pull that package from the EPEL repos as it's in EL since 5.2 now. I would have simply done it, but it turned out that the EVR in EPEL is higher then the one in EL:
$ sudo yum list trousers trousers.x86_64 0.3.1-5.el5 epel trousers.i386 0.3.1-5.el5 epel $ sudo yum list trousers --disablerepo=epel trousers.i386 0.3.1-4.el5 rhel-x86_64-serv trousers.x86_64 0.3.1-4.el5 rhel-x86_64-serv
So what do do? I tend a bit to say "remove it as long as the RHEL maintainer promises to ship the next updates with a release of '6' or higher". But that has downsides as well :-/ .
Comments?
The "naked" truth is -- I've asked the same question a while ago and nobody answered me. I maintain "python-setuptools" in EPEL, and it was included in RHEL5.2 -- also with a lower version. Honestly, there is no good solution to this, as removing the package from EPEL won't do much for those who already have it installed. This actually have bad security repercussions -- if EPEL used to provide foo-1.2 and RHEL5.2 ships with foo-1.1, then if there is a security issue with both of them, RH will likely backport it to foo-1.1 and thus everyone who had it installed from EPEL will remain vulnerable.
The *only* viable solution for when packages are pulled in from EPEL to RHEL proper is to either pull them in at the same version as EPEL, or to inflate the epoch for the package in RHEL so it always obsoletes EPEL (though this can also be tricky, as downgrading foo-1.2 to foo-1.1 can has undesired side-effects).
This is a policy decision that needs to be worked out between EPEL and RHEL -- preferably ASAP.
Regards,
On Sat, 2 Aug 2008, Konstantin Ryabitsev wrote:
The *only* viable solution for when packages are pulled in from EPEL to RHEL proper is to either pull them in at the same version as EPEL, or to inflate the epoch for the package in RHEL so it always obsoletes EPEL (though this can also be tricky, as downgrading foo-1.2 to foo-1.1 can has undesired side-effects).
This is a policy decision that needs to be worked out between EPEL and RHEL -- preferably ASAP.
I partially agree except that I'd say this is a policy decision that should be worked out between package maintianers. I suspect a bug filed against trousers would do the trick. Has anyone contacted the maintainer yet? No need for us all to get caught with our trousers around our ankles :)
-Mike
On 03.08.2008 16:58, Mike McGrath wrote:
On Sat, 2 Aug 2008, Konstantin Ryabitsev wrote:
The *only* viable solution for when packages are pulled in from EPEL to RHEL proper is to either pull them in at the same version as EPEL, or to inflate the epoch for the package in RHEL so it always obsoletes EPEL (though this can also be tricky, as downgrading foo-1.2 to foo-1.1 can has undesired side-effects). This is a policy decision that needs to be worked out between EPEL and RHEL -- preferably ASAP.
I partially agree except that I'd say this is a policy decision that should be worked out between package maintianers. I suspect a bug filed against trousers would do the trick. Has anyone contacted the maintainer yet?
The RHEL maintainer? Not as far as I know. Maybe the EPEL maintainer has, but I doubt it.
CU knurd
Mike McGrath wrote:
On Sat, 2 Aug 2008, Konstantin Ryabitsev wrote:
This is a policy decision that needs to be worked out between EPEL and RHEL -- preferably ASAP.
...
I partially agree except that I'd say this is a policy decision that should be worked out between package maintianers. I suspect a bug filed against trousers would do the trick. Has anyone contacted the maintainer yet? No need for us all to get caught with our trousers around our ankles :)
+1 Honestly, we (EPEL) can try to help, but at this point, there's not much EPEL can do about it. Make the the rhel maintainer aware of the issue(s), and then the ball is in their court.
Long term, rhel maintainers need to contact epel maintainers for future new rhel pkgs to try avoid anything like this in the future. I just don't see any other way.
-- Rex
-- Rex
On Mon, Aug 4, 2008 at 8:59 AM, Rex Dieter rdieter@math.unl.edu wrote:
This is a policy decision that needs to be worked out between EPEL and RHEL -- preferably ASAP.
...
I partially agree except that I'd say this is a policy decision that should be worked out between package maintianers. I suspect a bug filed against trousers would do the trick. Has anyone contacted the maintainer yet? No need for us all to get caught with our trousers around our ankles :)
+1 Honestly, we (EPEL) can try to help, but at this point, there's not much EPEL can do about it. Make the the rhel maintainer aware of the issue(s), and then the ball is in their court.
Long term, rhel maintainers need to contact epel maintainers for future new rhel pkgs to try avoid anything like this in the future. I just don't see any other way.
Right -- the question is whether Red Hat actually cares about what is going on in EPEL when they choose packages for inclusion in RHEL proper. I was always under the impression that RHEL and EPEL had an established working relationship that went both ways -- but perhaps not all RHEL devs are aware of the work we do with EPEL?
Maybe this is just an awareness campaign waiting to happen? :)
Regards,
On 04.08.2008 16:25, Konstantin Ryabitsev wrote:
I was always under the impression that RHEL and EPEL had an established working relationship that went both ways -- but perhaps not all RHEL devs are aware of the work we do with EPEL?
I'd compare the situation with Fedora Extras in the FC1-FC3 timeframe -- some RH employees are well aware of EPEL, other not so much ;-)
CU knurd
epel-devel@lists.fedoraproject.org
-
Konstantin Ryabitsev -
Mike McGrath -
Rex Dieter -
Thorsten Leemhuis