[opensuse-packaging] libraries renaming problems
Hi, I'm not sure whether this hasn't been discussed here a while ago, yet I'm running into it more and more often lately: as libraries packages are renamed according to shlib policy, they do not provide older names, which makes some software uninstallable (especially with the latest libzypp based tools). Typical example of this is: libfoo -> libfoo1 which doesn't provide "libfoo" (only "libfoo1" as it's its name). When other package Requires: "libfoo", the package manager (and eventually the user) gets fooled and isn't able to install the desired package. Write .spec files like: Name: libfoo %define major 1 %define minor whatever Version: %{major}.%{minor} %package -n %{name}%{major} Provides: %{name} = %{version} should help. Best regards Petr --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi,
On 2/22/2008 at 22:11, Petr Cerny <pcerny@suse.cz> wrote: Hi,
I'm not sure whether this hasn't been discussed here a while ago, yet I'm running into it more and more often lately: as libraries packages are renamed according to shlib policy, they do not provide older names, which makes some software uninstallable (especially with the latest libzypp based tools). Typical example of this is:
libfoo -> libfoo1 which doesn't provide "libfoo" (only "libfoo1" as it's its name). When other package Requires: "libfoo", the package manager (and eventually the user) gets fooled and isn't able to install the desired package.
I actually think that a package that explicitly Requires: libfoo should be verified. Why not use the symbolic file requires, but always point on a package? This is to restrictive in my opinion and causes to much trouble where it's not needed. I can think of only very very few packages where I ever Requires: <a specific package>... but really never did I have a Requires: for a shared library package in my spec files. Dominique --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Fri, 22 Feb 2008 21:11:42 +0100, Petr Cerny wrote:
When other package Requires: "libfoo", the package manager (and eventually the user) gets fooled and isn't able to install the desired package.
library packages should *never* be required explicitly as it's far better to have rpm determine the dependency automatically (with the exclusion of sub-packages of the library package). That will make a package dependent on the soname (i.e. internal name) of a library and will be resolved disregarding of the package name. Example: - libfoo1 contains libfoo.so.1.9.7 with soname libfoo.so.1. When packaging this with AutoReqProv on, rpmbuild will add libfoo.so.1 to libfoo1 provides. - Binary bar linked to libfoo will have the requirement for libfoo.so.1 encoded in it (as tools like ldd or objdump will show you) which in turn will be discovered by rpm and added to the Requires of the package containing this binary. When installing this package with an installer like zypper or smart that keeps a database of provides/requires, it will from this database detect that libfoo1.rpm is the package needed to resolve the dependency. When using rpm directly, you have to install libfoo1.rpm together with bar.rpm as rpm resolves dependencies only among those rpms installed together. That dependency won't break if you rename either or both packages, as the real dependency is the soname provided and required by the packages. So I don't really understand your problem. Philipp --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Mon, 25 Feb 2008, Philipp Thomas wrote:
On Fri, 22 Feb 2008 21:11:42 +0100, Petr Cerny wrote:
When other package Requires: "libfoo", the package manager (and eventually the user) gets fooled and isn't able to install the desired package.
I agree with all of the following...
library packages should *never* be required explicitly as it's far better to have rpm determine the dependency automatically (with the exclusion of sub-packages of the library package). That will make a package dependent on the soname (i.e. internal name) of a library and will be resolved disregarding of the package name. Example:
- libfoo1 contains libfoo.so.1.9.7 with soname libfoo.so.1. When packaging this with AutoReqProv on, rpmbuild will add libfoo.so.1 to libfoo1 provides.
- Binary bar linked to libfoo will have the requirement for libfoo.so.1 encoded in it (as tools like ldd or objdump will show you) which in turn will be discovered by rpm and added to the Requires of the package containing this binary.
... but the problem is probably that binaries and libraries were previously in a package libfoo and the other package just required one of the binaries (and such the libfoo package). The problem with the package split is now that the package containing the binaries got renamed(?) like libfoo --> foo \-> libfoo1 in this case the foo(!) package should provide and obsolete the libfoo name like Provides: libfoo = current-version Obsoletes: libfoo <= version-at-split-time split-provides should be also added for binaries here, like Provides: libfoo:/bin/foo But yes, the libfoo1 package should be never required directly (even if something dlopens a library, the requires should specify the name opened - in the most cases this is sth like /usr/lib/libfoo.so). Also the shared library package should not provide any old unsplit versions of the package. 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
On Monday 25 February 2008, Richard Guenther 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. 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. Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
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.
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. Ciao, Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
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 (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. 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.
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. 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
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)").
(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).
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 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. Ciao, Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
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
Hi, On Mon, 25 Feb 2008, Richard Guenther wrote:
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?
Nothing. Except that programs will open /usr/lib/libfoo.so or /usr/lib64/libfoo.so, if written correctly. Or even /usr/libexec/myapp/plugins/morepath/libdingdong.so , which even might move over several app versions.
File requires are nowhere evil or bad.
Nor good.
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.
Would work, yes.
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?)
That's true. Conclusion: we are screwed anyway, however we try to solve the problem ;-)
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).
Let's just hope that the amount of thinking doesn't just lead to overengineered solutions which solve no problem that ever happened :) Ciao, Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Philipp Thomas wrote:
On Fri, 22 Feb 2008 21:11:42 +0100, Petr Cerny wrote:
When other package Requires: "libfoo", the package manager (and eventually the user) gets fooled and isn't able to install the desired package.
library packages should *never* be required explicitly as it's far better to have rpm determine the dependency automatically (with the exclusion of sub-packages of the library package). That will make a package dependent on the soname (i.e. internal name) of a library and will be resolved disregarding of the package name. Example:
I agree. The point is, some packages do this (typically some from packman and even some from distro) - so this has been meant to provide some layer of compatibility for not-so-ideally packaged sw. My point is, that end users frustrated by not being able to install something from packman (typically something which we cannot provide in distro and OBS) will come complaining to us. Maybe some rpmlint check to alert when using "Requires: libfoo" appears in .spec file would help a little bit (if there isn't such a check already)? Best regards Petr --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Monday 25 February 2008, Petr Cerny wrote:
Maybe some rpmlint check to alert when using "Requires: libfoo" appears in .spec file would help a little bit (if there isn't such a check already)?
there is one already, explicit-lib-dependency. perhaps we should forbit explicit dependencies in lib packages, but looking at it, it would break 12 gnome-maintainers@ packages (and 19 packages affected in total). disallowing explicit lib dependencies in general breaks 42 gnome packages, 78 packages in total. Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Dirk Mueller escribió:
there is one already, explicit-lib-dependency.
Yes, and it works reasonably fine
perhaps we should forbit explicit dependencies in lib packages,
maybe giving that some higher badness rate..
disallowing explicit lib dependencies in general breaks 42 gnome packages, 78 packages in total.
Fixing that will be nice, they would hurt less then ;P -- "Morality is merely an interpretation of certain phenomena — more precisely, a misinterpretation." - Friedrich Nietzsche Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (7)
-
Cristian Rodríguez -
Dirk Mueller -
Dominique Leuenberger -
Michael Matz -
Petr Cerny -
Philipp Thomas -
Richard Guenther