On Wed, 15 Oct 2008, Hans de Goede wrote:
James Antill wrote:
On Wed, 2008-10-15 at 09:08 +0200, Oliver Falk wrote:
James Antill wrote:
[ ... ]
I can think of a Python 2.4 package that lives within the Zope tree to
make it extra hard for others to use it by accident - but I don't think
that this would be neat, seen from a FHS point of view.
In some ways this might be doable, at least it has less pain points
than packaging it "properly".
I'm not sure what you mean here? Do you mean with properly an
/usr/%{_lib}/python%{major}.{minor}/ installation? Well, I'd like to
invite everybody to have a look at the livna packages. Those are fine and
don't hurt the main python...
% repoquery --repoid=livna --provides compat-python24-imaging
_imaging.so()(64bit)
_imagingft.so()(64bit)
_imagingmath.so()(64bit)
compat-python24-imaging = 1.1.6-1.lvn9
% repoquery --provides python-imaging _imaging.so()(64bit)
_imagingft.so()(64bit)
_imagingmath.so()(64bit)
Yes rpmbuild is very broken in that it generates provides for .so files which
are not under libdir, so plugins for applications / libs / languages can have
conflicting Provides, luckily nothing should ever Require these plugins.
If something requires / can require them, how can they be "wrong"?
Not that I disagree, the above are silly and completely useless for all I
can tell. But how is rpmbuild going to know what's a real library
and what's not? %{_libdir} vs outside it is not going to work as it'd
cause perfectly legal uses of /etc/ld.so.conf.d and LD_LIBRARY_PATH
(both of which are runtime, not buildtime configuration items) to
break.
The question to me is: is there a way to *realiably* detect dlopen()'ed
modules from real libraries? There are a number of possible hints that can
be looked at, such as having DT_SONAME or not but AFAICT, it's all just
guesswork. Since the elf linker doesn't require DT_SONAME for shared
libraries, we'd break the dependency resolution of valid uses if we
filtered those out from provides generation.
As there doesn't seem to be hard rules (feel free to prove me wrong) we
can detect at build-time, then heuristics + manual overrides is the best
we can get. One possibility is a build configuration flag that allows
switching off generation of provides for DSO's without DT_SONAME, flip
that on in redhat-rpm-config and rebuild what's necessary. That'd be
essentially a one-liner patch to rpm.
Just to get an idea of what that would "gain": On my F9 + selected bits
from rawhide system, the number of DSO's in /%{_lib}, %{_libdir} and their
subdirectories is 3385. Roughly one third of them don't have DT_SONAME
set. Looking at the remaining ~2000, there's a lot of "unnecessary" stuff
left still.
But then, libtool seems to be putting soname into things built with
-module which makes the DT_SONAME test kinda moot already.
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
