On 04/27/2012 11:25 AM, Paul Howarth wrote:
On 04/27/2012 09:13 AM, Panu Matilainen wrote:
I started once again looking at ways to eliminate the unwanted provides
on private libs such as dlopen()'ed modules with minimal fuss and
breakage. Been down this route more than once but I suspect the last
time was before the major dependency generator changes in rpm-4.9.x,
which made tweaking these things a good deal easier, so time for another
round:
The short background is that for libraries which dont have a SONAME,
rpmbuild fakes one based on the file name. The rationale for this has
been that since the linker permits linking to libraries without sonames,
rpm must permit this too. The downside is that for the 1% corner cases
that need this, we end up polluting the provides namespace with
thousands of unnecessary and unwanted names, names that have not been
picked up with a global namespace in mind.
To get a rough idea just how much of this unwanted junk exists, using a
slightly modified elfdeps generator on my system:
This is how we currently generate the provides:
[root@localhost rpm]# find /lib64/ /usr/lib64/ -type f |./elfdeps -P
--soname-only --fake-soname|wc -l
3875
And this is without faked soname provides:
[root@localhost rpm]# find /lib64/ /usr/lib64/ -type f |./elfdeps -P
--soname-only |wc -l
2816
So... about a third of the soname provides are faked by using library
basename for its provide name, and almost all of them are for no good
reason. The three general cases that something actually depends on are
1) libreoffice sub-packages depending on its internal libraries from
libreoffice-core
2) a handful of packages depending on llvm libraries
3) bigger pile of packages depending on libperl.so
Of these at least 2) does look like a bug really, and in fact has been
fixed upstream: http://llvm.org/bugs/show_bug.cgi?id=12334. Dunno about
3), perl is... what it is. 1) might well classify as an inevitable
special case (there will always be those), dunno.
Obviously this is just a fairly small sample of the entire Fedora
package set, there are bound to be many more special cases, buggy
libraries which do not have SONAME when they should and stuff that falls
into gray areas. I can try to provide more comprehensive stats based on
current rawhide if needed.
I'm going to add a switch to allow packages to control the behavior
anyway. Whether rpm upstream defaults to the traditional behavior for
compatibility reasons or not is another question, but Fedora is
obviously free to override that. Given the packaging guideline mandate
to eliminate private soname provides from packages it seems like a
no-brainer to disable faked sonames by default, and require the handful
of special cases to work around it (adding enable-switches to specs)
instead of adding disable-switches to possibly hundreds of packages to
cater for the special cases needs.
Thoughts? This would obviously only change in rawhide.
Oh and of course eliminating the faked soname provides does not
eliminate all unwanted provides, eg libtool adds a soname even when
-module is used. But ... you need to start someplace.
Regarding perl, of the 48 packages that require libperl.so in Rawhide,
only 13 of them don't also require perl(:MODULE_COMPAT_5.14.2), which
will also pull in the perl-libs package, so I don't think perl is a big
issue.
In these cases, it's not a question of what other requires they might
have. If something links against a library (in this case libperl.so),
causing a require to be generated, something needs to provide that
dependency.
So in the case of libperl.so, the choices would basically be either:
a) Add an actual soname to libperl.so (since it's something that other
packages do link against, this would seem reasonable but then I dont
know the perl world pecularities at all...)
b) Enable the switch (whatever it will be) to generate these fake soname
provides in the main perl package (or add the provide manually in the
spec, but that gets ugly real fast)
- Panu -
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
