On Mon, 25 Feb 2008, Michael Matz wrote:
Hi,
On Mon, 25 Feb 2008, Richard Guenther wrote:
On Mon, 25 Feb 2008, Michael Matz wrote:
Hi,
On Mon, 25 Feb 2008, Dirk Mueller wrote:
the name opened - in the most cases this is sth like /usr/lib/libfoo.so).
I dislike this idea, because fileprovides cannot be versioned, so you're loosing vital dependency information.
Yeah, for this case I'd rather the package which has dlopening components to also simply mention the SONAME they open directly. I.e. exactly what also autoreqprov would find out if it were a real DT_NEEDED dependency.
Yep. That's the alternative to requiring /usr/lib/libfoo.so. But you need to do sth like
%ifarch x86_64 ia64 ppc64 s390x Provides: libgcj_bc.so.1()(64bit) %else Provides: libgcj_bc.so.1 %endif
Filenames have the very same problem (lib vs lib64), which could be solved in the same way (create a macro which expands to "" or "()(64bit)").
Sure. It still won't handle symbol versions then.
(with Requires: instead of course). Of course that doesn't help you if the application dlopens libfoo.so and that is in the libfoo-devel package (as required by the shlib policy) which does _not_ provide libfoo.so.1.
Theoretically (!) if bla.so is dlopened it isn't a shared lib, but a plugin/module/whatever you want to call it. And that doesn't belong into the xxx-devel package, but somewhere else (xxx-plugins or the main package or the like).
An application might choose to dlopen a regular shared library for optional features (think of liblame or such which we cannot distribute). For plugins we don't recomment to apply the shlib policy anyway.
So, the file requires is still needed here (unless you want to require libfoo-devel here). For versioning the soname requires should be added. Thus, do both in this case.
I really don't think file requires are going to cut it.
Well, if a program does dlopen('/usr/lib/libfoo.so') then it should require /usr/lib/libfoo.so. What is more natural than that? File requires are nowhere evil or bad.
For the same reason I don't think that filerequires for base packages are a good idea. unless you want to rewrite and revalidate all scripts in base to be compatible to the lowest common dominator. A pointless effort.
Hmm, a good point.
Not really. Scripts in the base packages should restrict themselves to whatever is provided by POSIX. (or LSB in our case)
You want that anyway, otherwise building a package for older versions will start to randomly fail based on whatever fancy new feature you used in your scripts.
With versioned requires (i.e. not file requires) the problem would be visible immediate instead of random errors occuring. I.e. this at least would allow stating the real requirements.
Well. So you for example do # this is in the shbang, so strictly requireed Requires: /usr/bin/python # we need python 2.5 at least Requires: python-features >= 2.5 and then python needs to provide that feature version. Or if it isn't that simple Requires: /bin/ls Requires: ls-color-support ugh. But a versioned requires doesn't cut it as well, as the same version of a program can be compiled with/without some features (busybox anyone?) Nobody said that proper Requires/Provides are easy, but at least for a core part of the distribution they should be done right (after spending enough amount of thinking of course). Richard. -- Richard Guenther <rguenther@suse.de> Novell / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org