10:21 a.m.
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
10:43 p.m.
On Thu, Feb 21, 2013 at 6:24 PM, Kevin Fenzi <kevin(a)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
10:54 p.m.
On Thu, Feb 21, 2013 at 9:43 PM, inode0 <inode0(a)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
11:04 p.m.
On Thu, Feb 21, 2013 at 10:54 PM, Ken Dreyer <ktdreyer(a)ktdreyer.com> wrote:
On Thu, Feb 21, 2013 at 9:43 PM, inode0 <inode0(a)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
11:43 p.m.
On Thu, Feb 21, 2013 at 10:43 PM, inode0 <inode0(a)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
9:48 a.m.
On Thu, 21 Feb 2013 22:43:50 -0600
inode0 <inode0(a)gmail.com> wrote:
On Thu, Feb 21, 2013 at 6:24 PM, Kevin Fenzi <kevin(a)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
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
4:55 a.m.
On Thu, 21 Feb 2013 22:43:50 -0600
inode0 <inode0(a)gmail.com> wrote:
On Thu, Feb 21, 2013 at 6:24 PM, Kevin Fenzi <kevin(a)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.
5:34 a.m.
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.
2:49 p.m.
Once upon a time, Paul Howarth <paul(a)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.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
3:53 p.m.
On Sat, 23 Feb 2013 14:49:59 -0600
Chris Adams <cmadams(a)hiwaay.net> wrote:
Once upon a time, Paul Howarth <paul(a)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.
4:19 p.m.
On Sat, Feb 23, 2013 at 3:53 PM, Paul Howarth <paul(a)city-fan.org> wrote:
On Sat, 23 Feb 2013 14:49:59 -0600
Chris Adams <cmadams(a)hiwaay.net> wrote:
> Once upon a time, Paul Howarth <paul(a)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
2:37 p.m.
On Sat, 23 Feb 2013 16:19:44 -0600
inode0 <inode0(a)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
10:55 a.m.
On Mon, Feb 25, 2013 at 2:37 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Sat, 23 Feb 2013 16:19:44 -0600
inode0 <inode0(a)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
6:46 p.m.
On dom, 2013-03-17 at 10:55 -0500, inode0 wrote:
On Mon, Feb 25, 2013 at 2:37 PM, Kevin Fenzi <kevin(a)scrye.com>
wrote:
> On Sat, 23 Feb 2013 16:19:44 -0600
> inode0 <inode0(a)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
8:10 p.m.
On Sun, Mar 17, 2013 at 6:46 PM, Dennis Gilmore <dennis(a)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
8:54 p.m.
On Sun, Mar 17, 2013 at 9:10 PM, inode0 <inode0(a)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
9:11 p.m.
On Sun, Mar 17, 2013 at 9:54 PM, Bryan J Smith <b.j.smith(a)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).
9:20 p.m.
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(a)gmail.com> wrote:
On Sun, Mar 17, 2013 at 9:54 PM, Bryan J Smith
<b.j.smith(a)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).
8:29 p.m.
[ 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(a)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(a)scrye.com> wrote:
> > On Sat, 23 Feb 2013 16:19:44 -0600
> > inode0 <inode0(a)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.
4055
days inactive
4080
days old
epel-devel@lists.fedoraproject.org
19 comments
9 participants
participants (9)
-
Bryan Smith -
Chris Adams -
Dennis Gilmore -
inode0 -
Jon Stanley -
Ken Dreyer -
Kevin Fenzi -
Manuel Wolfshant -
Paul Howarth