Greetings.
With the release of rhel 6.4, the following epel packages have been pulled in:
dev86 haproxy keepalived scipy suitesparse tbb
I'm going to mark these dead.package and block them later today unless someone screams. If maintainers need to bring them back for limited arch support or something, we can revive them.
kevin
On Thu, Feb 21, 2013 at 6:24 PM, Kevin Fenzi kevin@scrye.com wrote:
I've now marked these dead.package and blocked them in epel6.
This bz has been sitting around for over 4 months now and is the only obvious remaining case where an epel package stomps on a base RHEL6 package - perhaps someone can clean it up now too?
https://bugzilla.redhat.com/show_bug.cgi?id=867669
The following packages in epel currently have the same version as the same package in RHEL6 which can and does cause issues when the RHEL6 package isn't installed already. New installs and dependencies pull in the epel versions in a "defaultish" configuration. I don't see what purpose they really serve being in epel so if some of them can be removed that would be swell too.
a2ps emacs-a2ps emacs-a2ps-el html2ps libart_lgpl lzop perl-B-Keywords perl-Class-Accessor perl-Class-Data-Inheritable perl-Class-Trigger perl-Devel-Cycle perl-Email-Date-Format perl-Exception-Class perl-File-Copy-Recursive perl-Font-AFM perl-HTML-Format perl-Locale-PO perl-MIME-Lite perl-MIME-Types perl-Module-Find perl-Net-SMTP-SSL perl-PadWalker perl-Perl-Critic perl-Pod-Spell perl-String-Format perl-Syntax-Highlight-Engine-Kate perl-Test-Memory-Cycle perl-Test-Perl-Critic perl-UNIVERSAL-can perl-UNIVERSAL-isa perl-XML-TokeParser perl-XML-Writer ruby-shadow scons xhtml2ps
There are a couple with lower versions too. febootstrap ht2html
Thanks, John
On Thu, Feb 21, 2013 at 9:43 PM, inode0 inode0@gmail.com wrote:
ruby-shadow
Yeah, I noticed a while back that ruby-shadow appeared in EPEL, so Puppet can now be installed entirely via EPEL without having to enable the "optional" repo. I have a feeling that many servers probably have this one installed now.
- Ken
On Thu, Feb 21, 2013 at 10:54 PM, Ken Dreyer ktdreyer@ktdreyer.com wrote:
On Thu, Feb 21, 2013 at 9:43 PM, inode0 inode0@gmail.com wrote:
ruby-shadow
Yeah, I noticed a while back that ruby-shadow appeared in EPEL, so Puppet can now be installed entirely via EPEL without having to enable the "optional" repo. I have a feeling that many servers probably have this one installed now.
I didn't look closely at each of these conflicts and I omitted koan because it is in a standard channel that epel has never treated as part of a base RHEL system and ruby-shadow might be too. On my workstation it is in the rhn-tools channel which would be allowed as I understand it.
John
On Thu, Feb 21, 2013 at 10:43 PM, inode0 inode0@gmail.com wrote:
There are a couple with lower versions too. febootstrap ht2html
Actually there are closer to 30 packages in this category. They really don't hurt anything as far as I can tell so I won't add the rest here.
John
On Thu, 21 Feb 2013 22:43:50 -0600 inode0 inode0@gmail.com wrote:
On Thu, Feb 21, 2013 at 6:24 PM, Kevin Fenzi kevin@scrye.com wrote:
I've now marked these dead.package and blocked them in epel6.
This bz has been sitting around for over 4 months now and is the only obvious remaining case where an epel package stomps on a base RHEL6 package - perhaps someone can clean it up now too?
Done.
The following packages in epel currently have the same version as the same package in RHEL6 which can and does cause issues when the RHEL6 package isn't installed already. New installs and dependencies pull in the epel versions in a "defaultish" configuration. I don't see what purpose they really serve being in epel so if some of them can be removed that would be swell too.
Some of these may be there for other arch support. Ie, RHEL only shipps them on x86_64, but we need them for i686 and ppc in order to support EPEL packages on those arches.
I'm not sure how to tell that unless we also filter out those packages only shipped on x86_64 from the list.
kevin
On Thu, 21 Feb 2013 22:43:50 -0600 inode0 inode0@gmail.com wrote:
On Thu, Feb 21, 2013 at 6:24 PM, Kevin Fenzi kevin@scrye.com wrote:
I've now marked these dead.package and blocked them in epel6.
This bz has been sitting around for over 4 months now and is the only obvious remaining case where an epel package stomps on a base RHEL6 package - perhaps someone can clean it up now too?
https://bugzilla.redhat.com/show_bug.cgi?id=867669
The following packages in epel currently have the same version as the same package in RHEL6 which can and does cause issues when the RHEL6 package isn't installed already. New installs and dependencies pull in the epel versions in a "defaultish" configuration. I don't see what purpose they really serve being in epel so if some of them can be removed that would be swell too.
a2ps emacs-a2ps emacs-a2ps-el html2ps libart_lgpl lzop perl-B-Keywords perl-Class-Accessor perl-Class-Data-Inheritable perl-Class-Trigger perl-Devel-Cycle perl-Email-Date-Format perl-Exception-Class perl-File-Copy-Recursive perl-Font-AFM perl-HTML-Format perl-Locale-PO perl-MIME-Lite perl-MIME-Types perl-Module-Find perl-Net-SMTP-SSL perl-PadWalker perl-Perl-Critic perl-Pod-Spell perl-String-Format perl-Syntax-Highlight-Engine-Kate perl-Test-Memory-Cycle perl-Test-Perl-Critic perl-UNIVERSAL-can perl-UNIVERSAL-isa perl-XML-TokeParser perl-XML-Writer ruby-shadow scons xhtml2ps
Several of those perl packages are mine, dating back to the RHEL 6 beta, when we needed them for full arch support. What we did at the time was to rebuild the exact same package as RHEL to put in EPEL. I appreciate that that's not current policy and we'll do it differently for EPEL-7.
I'm sure I've suggested this before but I don't see why the epel-release package can't add a "cost" of >1000 (e.g. 1001) to the epel repos so that identical packages would always be picked up from RHEL in preference to EPEL.
Paul.
On 02/23/2013 12:55 PM, Paul Howarth wrote:
I'm sure I've suggested this before but I don't see why the epel-release package can't add a "cost" of>1000 (e.g. 1001) to the epel repos so that identical packages would always be picked up from RHEL in preference to EPEL.
Paul.
+1 to that. I've always thought that relying on cost/priorities to make 3rd party repos less preferable would be a good idea.
Once upon a time, Paul Howarth paul@city-fan.org said:
Several of those perl packages are mine, dating back to the RHEL 6 beta, when we needed them for full arch support. What we did at the time was to rebuild the exact same package as RHEL to put in EPEL. I appreciate that that's not current policy and we'll do it differently for EPEL-7.
I think it is still current policy; as another follow-up to that package list said, it needed to be checked for exactly what you said.
I'm sure I've suggested this before but I don't see why the epel-release package can't add a "cost" of >1000 (e.g. 1001) to the epel repos so that identical packages would always be picked up from RHEL in preference to EPEL.
That should be looked at as well, but there's no point in maintaining a package in EPEL that won't ever be used.
On Sat, 23 Feb 2013 14:49:59 -0600 Chris Adams cmadams@hiwaay.net wrote:
Once upon a time, Paul Howarth paul@city-fan.org said:
Several of those perl packages are mine, dating back to the RHEL 6 beta, when we needed them for full arch support. What we did at the time was to rebuild the exact same package as RHEL to put in EPEL. I appreciate that that's not current policy and we'll do it differently for EPEL-7.
I think it is still current policy; as another follow-up to that package list said, it needed to be checked for exactly what you said.
I'm sure I've suggested this before but I don't see why the epel-release package can't add a "cost" of >1000 (e.g. 1001) to the epel repos so that identical packages would always be picked up from RHEL in preference to EPEL.
That should be looked at as well, but there's no point in maintaining a package in EPEL that won't ever be used.
It's not that they won't ever be used; certainly for the perl modules that I did, they weren't available for ppc so that's why they got built.
Paul.
On Sat, Feb 23, 2013 at 3:53 PM, Paul Howarth paul@city-fan.org wrote:
On Sat, 23 Feb 2013 14:49:59 -0600 Chris Adams cmadams@hiwaay.net wrote:
Once upon a time, Paul Howarth paul@city-fan.org said:
Several of those perl packages are mine, dating back to the RHEL 6 beta, when we needed them for full arch support. What we did at the time was to rebuild the exact same package as RHEL to put in EPEL. I appreciate that that's not current policy and we'll do it differently for EPEL-7.
I think it is still current policy; as another follow-up to that package list said, it needed to be checked for exactly what you said.
I'm sure I've suggested this before but I don't see why the epel-release package can't add a "cost" of >1000 (e.g. 1001) to the epel repos so that identical packages would always be picked up from RHEL in preference to EPEL.
That should be looked at as well, but there's no point in maintaining a package in EPEL that won't ever be used.
It's not that they won't ever be used; certainly for the perl modules that I did, they weren't available for ppc so that's why they got built.
Your situation probably explains most of the two large groups where either we see the same version or we see a lower version lingering in EPEL.
Why not generate these lists and exclude the packages in question from the metadata built for architectures where they are included in RHEL?
John
On Sat, 23 Feb 2013 16:19:44 -0600 inode0 inode0@gmail.com wrote:
Your situation probably explains most of the two large groups where either we see the same version or we see a lower version lingering in EPEL.
Why not generate these lists and exclude the packages in question from the metadata built for architectures where they are included in RHEL?
Yeah, I suppose we could hard code such a list into mash.
I don't think the mash maintainers have time/desire to do this. Would anyone else be willing to look into it?
kevin
On Mon, Feb 25, 2013 at 2:37 PM, Kevin Fenzi kevin@scrye.com wrote:
On Sat, 23 Feb 2013 16:19:44 -0600 inode0 inode0@gmail.com wrote:
Your situation probably explains most of the two large groups where either we see the same version or we see a lower version lingering in EPEL.
Why not generate these lists and exclude the packages in question from the metadata built for architectures where they are included in RHEL?
Yeah, I suppose we could hard code such a list into mash.
I don't think the mash maintainers have time/desire to do this. Would anyone else be willing to look into it?
My lack of understanding the process is pretty limiting. Why in the world does it need to be hardcoded into anything? Surely mash can grab the list from a file or from the environment?!
John
On dom, 2013-03-17 at 10:55 -0500, inode0 wrote:
On Mon, Feb 25, 2013 at 2:37 PM, Kevin Fenzi kevin@scrye.com wrote:
On Sat, 23 Feb 2013 16:19:44 -0600 inode0 inode0@gmail.com wrote:
Your situation probably explains most of the two large groups where either we see the same version or we see a lower version lingering in EPEL.
Why not generate these lists and exclude the packages in question from the metadata built for architectures where they are included in RHEL?
Yeah, I suppose we could hard code such a list into mash.
I don't think the mash maintainers have time/desire to do this. Would anyone else be willing to look into it?
My lack of understanding the process is pretty limiting. Why in the world does it need to be hardcoded into anything? Surely mash can grab the list from a file or from the environment?!
John
mash is very simple. it takes the list of packages in the tag and makes a repo from them. making sure the rpms are signed by the key defined. it has no ability to do anything like has been proposed here. patches are welcome. but it would require a manually managed list of packages. since we don't have that info available. mash doesn't know about RHEL at all.
Dennis
On Sun, Mar 17, 2013 at 6:46 PM, Dennis Gilmore dennis@ausil.us wrote:
On dom, 2013-03-17 at 10:55 -0500, inode0 wrote:
My lack of understanding the process is pretty limiting. Why in the world does it need to be hardcoded into anything? Surely mash can grab the list from a file or from the environment?!
mash is very simple. it takes the list of packages in the tag and makes a repo from them. making sure the rpms are signed by the key defined. it has no ability to do anything like has been proposed here. patches are welcome. but it would require a manually managed list of packages. since we don't have that info available. mash doesn't know about RHEL at all.
Generating the list of packages that conflict is easy and there is a script that does that now. Does mash use createrepo to actually build the repo? If so I still can't imagine this is very difficult and if I get some free time I'll look at it.
John
On Sun, Mar 17, 2013 at 9:10 PM, inode0 inode0@gmail.com wrote:
Generating the list of packages that conflict is easy and there is a script that does that now. Does mash use createrepo to actually build the repo? If so I still can't imagine this is very difficult and if I get some free time I'll look at it.
Does createrepo need binary RPMS? Or can it get meta from SRPMS?
-- bjs
On Sun, Mar 17, 2013 at 9:54 PM, Bryan J Smith b.j.smith@ieee.org wrote:
Does createrepo need binary RPMS? Or can it get meta from SRPMS?
It needs the RPM's that you want to create the repo from :). If you want to create a repo of SRPM's, feed it a bunch of SRPM's. If you want a binary repo, feed it a bunch of binary RPM's.
createrepo is not a magical mind-reader, it can't infer what dependencies might be in a binary RPM once it's built. Remember that RPM itself puts all sorts of non-declared dependencies in a binary RPM that gets built (needed DSO's, provided DSO's, Perl deps, etc).
That's exactly what I thought. I think another tool would be required.
On Sun, Mar 17, 2013 at 10:11 PM, Jon Stanley jonstanley@gmail.com wrote:
On Sun, Mar 17, 2013 at 9:54 PM, Bryan J Smith b.j.smith@ieee.org wrote:
Does createrepo need binary RPMS? Or can it get meta from SRPMS?
It needs the RPM's that you want to create the repo from :). If you want to create a repo of SRPM's, feed it a bunch of SRPM's. If you want a binary repo, feed it a bunch of binary RPM's.
createrepo is not a magical mind-reader, it can't infer what dependencies might be in a binary RPM once it's built. Remember that RPM itself puts all sorts of non-declared dependencies in a binary RPM that gets built (needed DSO's, provided DSO's, Perl deps, etc).
[ FYI, top posting on purpose ]
This information should be in the SRPMS, correct? (Arch-specifics might be more difficult though). I'm thinking "out loud" here, so please excuse my ignorance of mash and related support here.
Before looking at the effort required, could someone tell me if the following solution be feasible? 1. Create a program to scrape through the SRPMS at ftp.redhat.com (at least under whatever directories are EPEL policy) and build an blacklist of packages? 2. Modify mash to never build a package if it is this blacklist?
As far as Arch, as a start, the list could be only used for the x86-64 EPEL repo. Or am I way off-the-mark of what is feasible?
-- bjs
On Sun, Mar 17, 2013 at 7:46 PM, Dennis Gilmore dennis@ausil.us wrote:
On dom, 2013-03-17 at 10:55 -0500, inode0 wrote:
On Mon, Feb 25, 2013 at 2:37 PM, Kevin Fenzi kevin@scrye.com wrote:
On Sat, 23 Feb 2013 16:19:44 -0600 inode0 inode0@gmail.com wrote:
Your situation probably explains most of the two large groups where either we see the same version or we see a lower version lingering in EPEL.
Why not generate these lists and exclude the packages in question from the metadata built for architectures where they are included in RHEL?
Yeah, I suppose we could hard code such a list into mash.
I don't think the mash maintainers have time/desire to do this. Would anyone else be willing to look into it?
My lack of understanding the process is pretty limiting. Why in the world does it need to be hardcoded into anything? Surely mash can grab the list from a file or from the environment?!
mash is very simple. it takes the list of packages in the tag and makes a repo from them. making sure the rpms are signed by the key defined. it has no ability to do anything like has been proposed here. patches are welcome. but it would require a manually managed list of packages. since we don't have that info available. mash doesn't know about RHEL at all.
epel-devel@lists.fedoraproject.org
-
Bryan Smith -
Chris Adams -
Dennis Gilmore -
inode0 -
Jon Stanley -
Ken Dreyer -
Kevin Fenzi -
Manuel Wolfshant -
Paul Howarth