On Mon, 25 Feb 2008, Richard Guenther wrote:
On Mon, 25 Feb 2008, Michael Matz wrote:
On Mon, 25 Feb 2008, Dirk Mueller wrote:
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
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)").
(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
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).
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.
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
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.
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org