Re: compat-python, Zope...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux