I have looked a bit at the provides in Core, and after a bit of creative repoquery use, came up with the list of duplicate provides below.
A bunch of them is intentional, like smtpdaemon, webclient or php_database. The bulk of it is due to non-library DSOs and is probably relatively harmless. Some of them may be real errors, like libmpi.so.0, perl(Class::Struct::Tie_ISA).
So it looks like things are in relatively good shape in Core. I haven't completed the same analysis for Core+Extras.
A couple of questions come out of this excercise:
1) Why does rpm keep all those non-library DSOs as provides ? Thats blowing up the list of provides significantly, causing a lot of duplicates, and is unlikely to ever be used for ever satisfying a requires, unless it is in error (e.g. see libsvg.so in the list)
2) Is rpm smart enough to disambiguate provides based on the full path, or is a provides for libsvg.so that lives in /usr/lib/compiz/libsvg.so going to be used to satisfy a requires for a shared library with the same name ? I guess this will rarely be a problem, since the shared library requirement will be against something like libsvg.so.4.
Matthias
Finally, the list:
postgresql-contrib: autoinc.so postgresql-test: autoinc.so mod_perl: Base64.so perl: Base64.so samba: cap.so zsh: cap.so aqbanking: csv.so.0 gwenhywfar: csv.so.0 python: datetime.so zsh: datetime.so xen: fsimage.so xen-libs: fsimage.so mailman: hangul.so scim-hangul: hangul.so rhpl: iconv.so ruby-libs: iconv.so scim-bridge-gtk: im-scim-bridge.so scim-bridge-qt: im-scim-bridge.so gnu-crypto-sasl-jdk1.4: java-sasl java-1.4.2-gcj-compat: java-sasl java-1.4.2-gcj-compat: jaxp_parser_impl xerces-j2: jaxp_parser_impl mkinitrd: libbdevid.so.6.0.6 nash: libbdevid.so.6.0.6 lam-libs: libmpi.so.0 openmpi-libs: libmpi.so.0 compiz: libsvg.so librsvg2: libsvg.so perl-DBD-MySQL: mysql.so php-mysql: mysql.so ccid: pcsc-ifd-handler ifd-egate: pcsc-ifd-handler automake15: perl(Class::Struct::Tie_ISA) perl: perl(Class::Struct::Tie_ISA) perl-Carp-Clan: perl(DB) perl: perl(DB) gaim: perl.so xchat: perl.so python: pyexpat.so PyXML: pyexpat.so python: readline.so ruby-libs: readline.so postgresql-contrib: refint.so postgresql-test: refint.so perl-PDL: RNG.so python-numeric: RNG.so postfix: smtpdaemon sendmail: smtpdaemon mod_perl: Socket.so perl: Socket.so perl-Crypt-SSLeay: SSLeay.so perl-Net-SSLeay: SSLeay.so perl-PDL: Storable.so perl: Storable.so python: syslog.so ruby-libs: syslog.so postfix: /usr/bin/mailq sendmail: /usr/bin/mailq postfix: /usr/bin/newaliases sendmail: /usr/bin/newaliases postfix: /usr/bin/rmail sendmail: /usr/bin/rmail postfix: /usr/sbin/sendmail sendmail: /usr/sbin/sendmail mod_perl: Util.so perl: Util.so ImageMagick: xc.so xen: xc.so php-mysql: php_database php-odbc: php_database php-pgsql: php_database selinux-policy-mls: selinux-policy-base selinux-policy-strict: selinux-policy-base selinux-policy-targeted: selinux-policy-base gnome-python2-bonobo: ui.so gnome-python2-gnomeprint: ui.so gnome-python2: ui.so ruby-libs: socket.so scim-libs: socket.so scim: socket.so zsh: socket.so elinks: webclient firefox: webclient lynx: webclient w3m: webclient wget: webclient
On Fri, Jan 26, 2007 at 01:11:33AM -0500, Matthias Clasen wrote:
- Why does rpm keep all those non-library DSOs as provides ? Thats
blowing up the list of provides significantly, causing a lot of duplicates, and is unlikely to ever be used for ever satisfying a requires, unless it is in error (e.g. see libsvg.so in the list)
In /usr/lib/rpm/find-provides the list of files is constructed by using solist=$(echo $filelist | grep "\.so" | grep -v "^/lib/ld.so" | \ xargs file -L 2>/dev/null | grep "ELF.*shared object" | cut -d: -f1)
- Is rpm smart enough to disambiguate provides based on the full path,
or is a provides for libsvg.so that lives in /usr/lib/compiz/libsvg.so going to be used to satisfy a requires for a shared library with the same name ? I guess this will rarely be a problem, since the shared library requirement will be against something like libsvg.so.4.
In general it is not a problem, but I think that this should be avoided. It has been already pointed out in lists, and in numerous package submissions (I always look for sane provides and for perl packages there are the 'usual bogusprovides on .so files'). I just have filled a bug against rpm:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224544
Another possible solution would be to avoid setting the SONAME for the files that are only to be dlopened. libtool always set the soname, and it seems to be the same for perl. Maybe this is where things should be fixed?
-- Pat
On Fri, 2007-01-26 at 11:11 +0100, Patrice Dumas wrote:
On Fri, Jan 26, 2007 at 01:11:33AM -0500, Matthias Clasen wrote:
In general it is not a problem, but I think that this should be avoided.
In most cases this is not a problem for RH/Fedora. But it is a problem outside of RH/Fedora, e.g. for 3rd party packages designed for parallel installation, containing DSOs with the same names as Fedora.
It has been already pointed out in lists, and in numerous package submissions (I always look for sane provides and for perl packages there are the 'usual bogusprovides on .so files'). I just have filled a bug against rpm:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224544
Another possible solution would be to avoid setting the SONAME for the files that are only to be dlopened. libtool always set the soname, and it seems to be the same for perl. Maybe this is where things should be fixed?
Nope, the bug is in rpmbuild rsp. redhat-rpm-config. They produce invalid results.
Ralf
To justify the time I invested in this excercise, I filed bugs for a few of the more obviously wrong cases:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224569 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224571
So, how does this list like the idea of adding a bulletpoint for "sane provides" to the package review guidelines ?
On Friday 26 January 2007 10:29, Matthias Clasen wrote:
So, how does this list like the idea of adding a bulletpoint for "sane provides" to the package review guidelines ?
I like it. However, defining 'sane provides' might prove difficult, but if you have pointers or a draft bullet point I'd gladly read it (:
On Fri, 2007-01-26 at 10:45 -0500, Jesse Keating wrote:
On Friday 26 January 2007 10:29, Matthias Clasen wrote:
So, how does this list like the idea of adding a bulletpoint for "sane provides" to the package review guidelines ?
I like it. However, defining 'sane provides' might prove difficult, but if you have pointers or a draft bullet point I'd gladly read it (:
Its hard to make that very precise, but it should mean something like
Look at the list of provides and verify that all of them are intentional. Use repoquery to check if other packages already provide the same thing, and if so, look closer. This is generally ok if the provides is for a .so that lives outside of LIBDIR, otherwise it indicates a potential problem.
Matthias Clasen (mclasen@redhat.com) said:
Its hard to make that very precise, but it should mean something like
Look at the list of provides and verify that all of them are intentional. Use repoquery to check if other packages already provide the same thing, and if so, look closer. This is generally ok if the provides is for a .so that lives outside of LIBDIR, otherwise it indicates a potential problem.
Maybe also:
If your package provides perl(<anything>), and either:
a) your package is not a perl module - or - b) your package is not named the same <anything>
it is almost certainly a bug.
Bill
"MC" == Matthias Clasen mclasen@redhat.com writes:
MC> So, how does this list like the idea of adding a bulletpoint for MC> "sane provides" to the package review guidelines ?
I have always checked these in my reviews; I list out the dependencies so that others who happen to peruse the reviews can perhaps spot anything that I miss. It's caught problems in the past.
Of course, as others have pointed out, it's tough to define "sane". I generally know a bogus provide when I see one, but I don't think I could list out all of the criteria.
- J<
On Fri, 2007-01-26 at 10:29 -0500, Matthias Clasen wrote:
To justify the time I invested in this excercise, I filed bugs for a few of the more obviously wrong cases:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224569 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224571
IMO, these are different cases, with similar symptoms, but with different causes than the "bogus DSO/shared lib 'Provides'".
I think, 1. The "<lib>.so provides" should be tied to "ld.so's library search path" 2. The "perl() provides" (BZ 224569) should be tied to Perl's "module search-path".
3. BZ 224571 sounds like a bug in rpm's perl-reqprov filtering (Which is known to be pretty underdeveloped/immature and to quite frequently generate bogus/missing provide/requires)
I know, many people will disagree, but IMO, 1+2 would not be an issue if rpm was using absolute filenames to DSO's/modules instead of virtual provides.
So, how does this list like the idea of adding a bulletpoint for "sane provides" to the package review guidelines ?
Could you elaborate? I don't understand.
Ralf
packaging@lists.fedoraproject.org
-
Bill Nottingham -
Jason L Tibbitts III -
Jesse Keating -
Matthias Clasen -
Patrice Dumas -
Ralf Corsepius