11:09 a.m.
Ok if my cave man hacking attempts were correct then this is the list
of things that in EPEL beats EL-5 stuff:
Looking up all competing providers
Got all the potential problems, checking them
==================================================================
==================================================================
Requirement problems
==================================================================
qspice-libs-devel-0.3.0-39.el5.x86_64 requires libspice.so.0()(64bit)
epel wins with tclspice
tclspice - epel
qspice-libs - el5
==================================================================
kvm-tools-83-105.el5.x86_64 requires libspice.so.0()(64bit)
epel wins with tclspice
tclspice - epel
qspice-libs - el5
==================================================================
lapack-3.0-37.el5.x86_64 requires liblapack.so.3()(64bit)
epel wins with atlas
atlas - epel
lapack - el5
==================================================================
perl-libwww-perl-5.805-1.1.1.noarch requires perl(LWP::Protocol)
epel wins with perl-SOAP-Lite
perl-SOAP-Lite - epel
perl-libwww-perl - el5
==================================================================
cman-2.0.115-1.el5.x86_64 requires perl(Net::Telnet)
epel wins with perl-Net-Telnet
perl-Net-Telnet - epel
perl-Net-Telnet - el5
==================================================================
libvirt-0.6.3-20.el5.x86_64 requires /usr/bin/qemu-img
epel wins with qemu-img
qemu-img - epel
kvm-qemu-img - el5
==================================================================
qspice-libs-0.3.0-39.el5.x86_64 requires libspice.so.0()(64bit)
epel wins with tclspice
tclspice - epel
qspice-libs - el5
==================================================================
1:perl-LDAP-0.33-3.fc6.noarch requires perl(LWP::Protocol)
epel wins with perl-SOAP-Lite
perl-SOAP-Lite - epel
perl-libwww-perl - el5
==================================================================
==================================================================
cman-2.0.115-1.el5.x86_64 requires perl(Net::Telnet)
epel wins with perl-Net-Telnet
perl-Net-Telnet - epel
perl-Net-Telnet - el5
==================================================================
libvirt-0.6.3-20.el5.x86_64 requires /usr/bin/qemu-img
epel wins with qemu-img
qemu-img - epel
kvm-qemu-img - el5
==================================================================
qspice-libs-0.3.0-39.el5.x86_64 requires libspice.so.0()(64bit)
epel wins with tclspice
tclspice - epel
qspice-libs - el5
==================================================================
1:perl-LDAP-0.33-3.fc6.noarch requires perl(LWP::Protocol)
epel wins with perl-SOAP-Lite
perl-SOAP-Lite - epel
perl-libwww-perl - el5
==================================================================
kvm-qemu-img-83-105.el5.x86_64 requires libspice.so.0()(64bit)
epel wins with tclspice
tclspice - epel
qspice-libs - el5
==================================================================
lapack-devel-3.0-37.el5.x86_64 requires liblapack.so.3()(64bit)
epel wins with atlas
atlas - epel
lapack - el5
==================================================================
kvm-83-105.el5.x86_64 requires libspice.so.0()(64bit)
epel wins with tclspice
tclspice - epel
qspice-libs - el5
==================================================================
--
Stephen J Smoogen.
Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning
11:32 a.m.
Stephen John Smoogen wrote:
Ok if my cave man hacking attempts were correct then this is the
list
of things that in EPEL beats EL-5 stuff:
Looking up all competing providers
Got all the potential problems, checking them
==================================================================
lapack-devel-3.0-37.el5.x86_64 requires liblapack.so.3()(64bit)
epel wins with atlas
atlas - epel
lapack - el5
That liblapack.so.3 is tucked away in /usr/lib64/atlas/ and isn't on the
library path by default IIRC.
Mark
noon
On Fri, Mar 12, 2010 at 10:32 AM, Mark Chappell <tremble(a)tremble.org.uk> wrote:
Stephen John Smoogen wrote:
> Ok if my cave man hacking attempts were correct then this is the list
> of things that in EPEL beats EL-5 stuff:
>
> Looking up all competing providers
> Got all the potential problems, checking them
> ==================================================================
> lapack-devel-3.0-37.el5.x86_64 requires liblapack.so.3()(64bit)
> epel wins with atlas
> atlas - epel
> lapack - el5
That liblapack.so.3 is tucked away in /usr/lib64/atlas/ and isn't on the
library path by default IIRC.
What I did was compare the list of provides with the list of requires.
One package requires liblapack and another says it provides it. My
compare routine may need some work to make it better :).
--
Stephen J Smoogen.
Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning
12:30 p.m.
The important question would I suppose be what does RPM/Yum do with them...
I've a nasty feeling it uses lapack by default, but will use atlas for
dep solving if it's already installed.
Mark
On 12/03/2010, Stephen John Smoogen <smooge(a)gmail.com> wrote:
On Fri, Mar 12, 2010 at 10:32 AM, Mark Chappell
<tremble(a)tremble.org.uk>
wrote:
> Stephen John Smoogen wrote:
>> Ok if my cave man hacking attempts were correct then this is the list
>> of things that in EPEL beats EL-5 stuff:
>>
>> Looking up all competing providers
>> Got all the potential problems, checking them
>> ==================================================================
>> lapack-devel-3.0-37.el5.x86_64 requires liblapack.so.3()(64bit)
>> epel wins with atlas
>> atlas - epel
>> lapack - el5
>
>
> That liblapack.so.3 is tucked away in /usr/lib64/atlas/ and isn't on the
> library path by default IIRC.
What I did was compare the list of provides with the list of requires.
One package requires liblapack and another says it provides it. My
compare routine may need some work to make it better :).
--
Stephen J Smoogen.
Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning
_______________________________________________
epel-devel-list mailing list
epel-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
12:55 p.m.
Once upon a time, Mark Chappell <tremble(a)tremble.org.uk> said:
The important question would I suppose be what does RPM/Yum do with
them...
I've a nasty feeling it uses lapack by default, but will use atlas for
dep solving if it's already installed.
Shortest name wins, so atlas gets pulled in (when it doesn't actually
meet a needed dependency). I would think the bug is in the atlas
packaging; the RPM shouldn't list a shared lib outside the standard
directories as a provide.
This is similar to mrtg vs. perl-SNMP_Session; mrtg has its own private
copy of the SNMP_Session perl modules, but they are found by the
auto-provides (so the RPM lists them). Then mrtg is a shorter name than
perl-SNMP_Session, so a package requiring "perl(SNMP_Session)" gets a
broken install.
--
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.
1:28 p.m.
On Friday 12 March 2010, Chris Adams wrote:
This is similar to mrtg vs. perl-SNMP_Session; mrtg has its own
private
copy of the SNMP_Session perl modules, but they are found by the
auto-provides (so the RPM lists them). Then mrtg is a shorter name than
perl-SNMP_Session, so a package requiring "perl(SNMP_Session)" gets a
broken install.
https://bugzilla.redhat.com/show_bug.cgi?id=563619
1:57 p.m.
Once upon a time, Ville Skyttä <ville.skytta(a)iki.fi> said:
On Friday 12 March 2010, Chris Adams wrote:
> This is similar to mrtg vs. perl-SNMP_Session; mrtg has its own private
> copy of the SNMP_Session perl modules, but they are found by the
> auto-provides (so the RPM lists them). Then mrtg is a shorter name than
> perl-SNMP_Session, so a package requiring "perl(SNMP_Session)" gets a
> broken install.
https://bugzilla.redhat.com/show_bug.cgi?id=563619
Yeah, that's a dupe of my 4 month old bug:
https://bugzilla.redhat.com/show_bug.cgi?id=532556
I looked at the RHEL 5.5 beta, but I didn't see a new mrtg package.
--
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.
2:39 p.m.
On Fri, Mar 12, 2010 at 12:57 PM, Chris Adams <cmadams(a)hiwaay.net> wrote:
Once upon a time, Ville Skyttä <ville.skytta(a)iki.fi> said:
> On Friday 12 March 2010, Chris Adams wrote:
> > This is similar to mrtg vs. perl-SNMP_Session; mrtg has its own private
> > copy of the SNMP_Session perl modules, but they are found by the
> > auto-provides (so the RPM lists them). Then mrtg is a shorter name than
> > perl-SNMP_Session, so a package requiring "perl(SNMP_Session)" gets a
> > broken install.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=563619
Yeah, that's a dupe of my 4 month old bug:
https://bugzilla.redhat.com/show_bug.cgi?id=532556
I looked at the RHEL 5.5 beta, but I didn't see a new mrtg package.
Is there something we can put in the spec files to tell RPM not to look at it?
--
Stephen J Smoogen.
Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning
2:45 p.m.
On Fri, 12 Mar 2010 13:39:49 -0700
Stephen John Smoogen <smooge(a)gmail.com> wrote:
On Fri, Mar 12, 2010 at 12:57 PM, Chris Adams
<cmadams(a)hiwaay.net>
wrote:
> Once upon a time, Ville Skyttä <ville.skytta(a)iki.fi> said:
>> On Friday 12 March 2010, Chris Adams wrote:
>> > This is similar to mrtg vs. perl-SNMP_Session; mrtg has its own
>> > private copy of the SNMP_Session perl modules, but they are
>> > found by the auto-provides (so the RPM lists them). Then mrtg
>> > is a shorter name than perl-SNMP_Session, so a package requiring
>> > "perl(SNMP_Session)" gets a broken install.
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=563619
>
> Yeah, that's a dupe of my 4 month old bug:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=532556
>
> I looked at the RHEL 5.5 beta, but I didn't see a new mrtg package.
Is there something we can put in the spec files to tell RPM not to
look at it?
Packages requiring perl(SNMP_Session) could add a manual dependency on
perl-SNMP_Session; this will pick up the wanted package and won't be
fooled by the imposter.
Paul.
2:51 p.m.
Once upon a time, Paul Howarth <paul(a)city-fan.org> said:
Packages requiring perl(SNMP_Session) could add a manual dependency
on
perl-SNMP_Session; this will pick up the wanted package and won't be
fooled by the imposter.
It is much better to fix the broken package (RHEL's mrtg in this case)
than break all the other packages (what if a new version of
SNMP_Session.pm becomse part of some other package?).
--
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:07 p.m.
On Fri, 12 Mar 2010 14:51:00 -0600
Chris Adams <cmadams(a)hiwaay.net> wrote:
Once upon a time, Paul Howarth <paul(a)city-fan.org> said:
> Packages requiring perl(SNMP_Session) could add a manual dependency
> on perl-SNMP_Session; this will pick up the wanted package and
> won't be fooled by the imposter.
It is much better to fix the broken package (RHEL's mrtg in this case)
than break all the other packages (what if a new version of
SNMP_Session.pm becomse part of some other package?).
Well of course but that's outside of our control and as mentioned
earlier in the thread, it's a known problem but nothing has been done
about it in RHEL.
Paul.
2:49 p.m.
Once upon a time, Stephen John Smoogen <smooge(a)gmail.com> said:
On Fri, Mar 12, 2010 at 12:57 PM, Chris Adams
<cmadams(a)hiwaay.net> wrote:
> Once upon a time, Ville Skyttä <ville.skytta(a)iki.fi> said:
>> On Friday 12 March 2010, Chris Adams wrote:
>> > This is similar to mrtg vs. perl-SNMP_Session; mrtg has its own private
>> > copy of the SNMP_Session perl modules, but they are found by the
>> > auto-provides (so the RPM lists them). Then mrtg is a shorter name than
>> > perl-SNMP_Session, so a package requiring "perl(SNMP_Session)"
gets a
>> > broken install.
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=563619
>
> Yeah, that's a dupe of my 4 month old bug:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=532556
>
> I looked at the RHEL 5.5 beta, but I didn't see a new mrtg package.
Is there something we can put in the spec files to tell RPM not to look at it?
You have to disable internal dependency generation, filter the provides
(to not provide the private thing), and filter the requires (to not
require the thing you are no longer internally providing but presumably
depending on).
The Fedora mrtg package does this with an external script; you can also
do it right in the spec file.
https://fedoraproject.org/wiki/Packaging/Perl#Filtering_Requires:_and_Pro...
https://fedoraproject.org/wiki/PackagingDrafts/FilteringAutomaticDependen...
--
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.
2:55 p.m.
On Fri, 12 Mar 2010 17:32:39 +0000
Mark Chappell <tremble(a)tremble.org.uk> wrote:
Stephen John Smoogen wrote:
> Ok if my cave man hacking attempts were correct then this is the
> list of things that in EPEL beats EL-5 stuff:
>
> Looking up all competing providers
> Got all the potential problems, checking them
> ==================================================================
> lapack-devel-3.0-37.el5.x86_64 requires liblapack.so.3()(64bit)
> epel wins with atlas
> atlas - epel
> lapack - el5
That liblapack.so.3 is tucked away in /usr/lib64/atlas/ and isn't on
the library path by default IIRC.
It shouldn't be providing liblapack.so.3 at all; the bogus provide can
be filtered out by doing something like this:
# Don't "provide" our private libs, or generate doc-file dependencies
%global _use_internal_dependency_generator 0
%global docfilt perl -p -e 's|%{_docdir}/%{name}-%{version}\\S+||'
%global so_filt grep -v '%{_libdir}/atlas/.*$'
%global __deploop() while read FILE; do /usr/lib/rpm/rpmdeps -%{1} ${FILE}; done |
/bin/sort -u
%global __find_provides /bin/sh -c "%{so_filt} | %{__deploop P}"
%global __find_requires /bin/sh -c "%{docfilt} | %{__deploop R}"
This is how the filtering macros described at
https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering
work, but they're only available in recent Fedora releases.
Paul.
5152
days inactive
5152
days old
epel-devel@lists.fedoraproject.org
12 comments
5 participants
participants (5)
-
Chris Adams -
Mark Chappell -
Paul Howarth -
Stephen John Smoogen -
Ville Skyttä