compat-python, Zope...

Panu Matilainen pmatilai at laiskiainen.org
Thu Oct 16 07:53:49 UTC 2008


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 -




More information about the fedora-devel-list mailing list