[opensuse-packaging] .la files and dependencies, again
Hi, I just had a look on popt (which packages it has a dependency on, which packages depend on it) and was again astonished by the impact its .la file (/usr/lib/libpopt.la) has. Only very few packages really require popt (rpm and libgnome, to name a few). But the .la file infects all packages above them in the dependency chain so that they will also depend on popt even if they don't have to. This happens to affect mostly GNOME packages... The following packages currently have dependencies on popt-devel although they don't #include <popt.h>: gnome-bluetooth-devel gstreamer010-devel libgnomeui-devel libzypp-devel orbit2-devel Why? Because of a libtool dependency check that completely ignores the fact that these dependencies are generated by the .la files. The .la files are not storing actual dependencies, they are generating new ones. Just as an example: # grep popt /usr/lib/libzypp.la dependency_libs=' /usr/lib/libxml2.la -lcurl /usr/lib/libidn.la -lssl -lcrypto /usr/lib/librpm.la /usr/lib/librpmdb.la /usr/lib/librpmio.la -ldl -lpthread -lz -lbz2 /usr/lib/libpopt.la /usr/lib/libgobject-2.0.la /usr/lib/libdbus-glib-1.la /usr/lib/libgobject-2.0.la /usr/lib/libglib-2.0.la -lnsl /usr/lib/libglib-2.0.la -lrt /usr/lib/libhal-storage.la /usr/lib/libhal.la /usr/lib/libhal.la /usr/lib/libdbus-1.la /usr/lib/libdbus-1.la -lboost_regex -lboost_filesystem -lutil' But: # rpm -ql libzypp-devel | xargs grep popt\\.h (no matches) # ldd -u -r /usr/bin/zypper Unused direct dependencies: /usr/lib/libpopt.so.0 In fact there is no need to link zypp-based programs to popt because zypp does not expose it, but libtool adds it anyway just because /usr/lib/librpm.la has it. In short, .la files always contain as many dependencies as possible. These dependencies were not present if the packages were not installing their .la files. Another flaw with this approach is that it's a one-way thing. Dependencies are added if needed, but never removed. Example: Some time ago, a package really used popt, so the check told you to add "Requires: popt-devel" to the -devel package. Later, the package stops using popt, but the check doesn't notice that and the dependency will stay forevermore. This is especially annoying if the authors of this package spent resources into getting rid of that dependency. # rpm -ql libnotify-devel | grep \\.la /usr/lib/libnotify.la # grep popt /usr/lib/libnotify.la (no matches) # rpm -ql libnotify-devel | xargs grep popt\\.h (no matches) And now the worst thing: # rpm -ql libnotify | xargs grep popt /usr/share/doc/packages/libnotify/ChangeLog: - Patch by M.S. to switch notify-send to use GOption instead of popt, /usr/share/doc/packages/libnotify/NEWS: * Patch by M.S. to switch notify-send to use GOption instead of popt, But it happily requires popt-devel anyway: # rpm -q --requires libnotify-devel | grep popt popt-devel There is no way to get rid of these again other than manually looking at the packages and manually trying to find out why the dependencies have been added and if they are still needed. ARGH! Andreas Hanke -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, Feb 20, 2007 at 11:24:47AM +0100, andreas.hanke@gmx-topmail.de wrote:
Hi,
I just had a look on popt (which packages it has a dependency on, which packages depend on it) and was again astonished by the impact its .la file (/usr/lib/libpopt.la) has.
Only very few packages really require popt (rpm and libgnome, to name a few). But the .la file infects all packages above them in the dependency chain so that they will also depend on popt even if they don't have to. This happens to affect mostly GNOME packages...
The following packages currently have dependencies on popt-devel although they don't #include <popt.h>:
There is a problem in your argumentation. Whereas it does not make sense to specify implicit dependencies for shared libraries it does for static libraries. Even if you don't use a specific library directly it might be a requirement to link to this specific library when using static libraries because another library you are using depends on that. Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."
Hi,
There is a problem in your argumentation. Whereas it does not make sense to specify implicit dependencies for shared libraries it does for static libraries. Even if you don't use a specific library directly it might be a requirement to link to this specific library when using static libraries because another library you are using depends on that.
I am aware of this difference, but there is something else to consider: Nowadays, many packages are not even installing static libraries any more. KDE3 packages, for example, traditionally don't install any static libraries (and if some package does it, they are removed very quickly). They are installing .la files (needed because of libltdl...), but they are not affected by the indirect dependency problem because they are using --as-needed. Other packages like libzypp and glib2 are not installing static libraries either, but their "consumers" inherit all private dependencies anyway because of the .la files. In the case of libzypp and glib2 (and all libraries built on top of glib2), the usefulness of their .la files is highly questionable because they cannot be used to create static executables anyway. With libzypp.la, but no libzypp.a this is just impossible. They could be used to create semi-static executables (where some libraries are linked static and others shared), but for this purpose, the .la files of pure shared libraries are not needed. Andreas Hanke -- "Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ... Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, Feb 20, 2007 at 02:49:48PM +0100, andreas.hanke@gmx-topmail.de wrote:
Hi,
There is a problem in your argumentation. Whereas it does not make sense to specify implicit dependencies for shared libraries it does for static libraries. Even if you don't use a specific library directly it might be a requirement to link to this specific library when using static libraries because another library you are using depends on that.
I am aware of this difference, but there is something else to consider: Nowadays, many packages are not even installing static libraries any more.
Sure but this is the whole problem of almost all libtool discussions: People tend to generalize into one direction, skipping the other side of the story completely. It seems that libtool is quite a religios product. Most people are either for it or against it but almost nobody ever explain what exactly the problems are he currently suffers from. There is one group of people that always uses libtool for everything even when using the standard C library only and there is the group of people that for every single problem they see in using libtool just say that libtool is crap and that nobody never ever wants to use it. Actually that way these problems never get fixed because people just run away and instead reinvent the wheel. So in this specific case you are right that libtool does not handle the shared library case in a smart way but you cannot say that listing this dependencies is completely wrong. The design of the tool just does not match all use cases in a really good manner. Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."
Hi,
Sure but this is the whole problem of almost all libtool discussions: People tend to generalize into one direction, skipping the other side of the story completely.
It seems that libtool is quite a religios product [...]
Sorry, this is absolutely not the point of my post and libtool isn't the only the problem, it's just a symptom. I'm just trying to find out why various packages have so many and partially obsolete dependencies and found that .la files are 1 particular type of dependency generators, but there are others, e.g. seemingly harmless directories. As long as .la files are present (and removing all of them would probably be overkill), they do carry dependency information that must somehow be used by the package manager because otherwise libtool won't be able to cope with the packages. So far there's no problem. The problem is the way dependency information is extracted from .la files and transfered into the packages. The current approach seems to look at all .la files in the buildroot, then it tells the packager which packages provide the other .la files that a certain .la file depends on and finally translates this into a package name and asks the packager to add this package name to "Requires". This approach (the manual translation into a package name) is horribly broken because it cannot be undone automatically. Once the dependency disappears, the package name will remain in "Requires" until someone removes it manually. This concept cannot work because nobody wants to constantly re-check the dependencies. This results in packages with excess dependencies. There are various reasons why such a semi-automatically added dependency can become obsolete. A package might have stopped using a library or the library package might have been split, renamed or whatever. A sane check that does not automatically add, but also automatically remove dependencies must work without the manual translation into a package name. This could be done by fully automatically adding Requires: /usr/lib/libpopt.la via a find-requires script instead of a brp script that prints "please add popt-devel to Requires". If the .la file later no longer references libpopt.la, the find-requires script will no longer automatically add this and the dependency just disappears without manual intervention. If it really has to work with package names, something like Requires: %(rpm -qf --qf '%{NAME}\n' /usr/lib/libpopt.la) can be used. But the filename-based dependency is the better option because libtool really needs the .la files with their absolute filename, it refuses to work if they were moved because it doesn't support the concept of a search path and the packagename-based approach doesn't reflect the fact that e.g. all legacy /opt/gnome .la files are broken now. The dependencies are still fulfilled, but the .la files don't work. To illustrate why libtool is just 1 side of the problem, look at how many packages currently require gnome-icon-theme. Most of them don't require any icons from this package, they require the package just because of the /usr/share/icons/hicolor directory hierarchy. Just now, this directory hierarchy has been split off from gnome-icon-theme into a new package, hicolor-icon-theme. But all the packages still happily require gnome-icon-theme anyway although they don't need it any more just because the dependency (which originates from directory ownership) has been translated into a package name. The check that is responsible for directory ownership dependencies should simply add Requires: /usr/share/icons/hicolor This way the dependencies automatically remain correct even if the provider of this directory changes. There are good reasons why rpm doesn't translate "Requires: libc.so.6" into "Requires: glibc", the same rationale applies here. Andreas Hanke -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, On Wed, 21 Feb 2007, andreas.hanke@gmx-topmail.de wrote:
The problem is the way dependency information is extracted from .la files and transfered into the packages. The current approach seems to look at all .la files in the buildroot, then it tells the packager which packages provide the other .la files that a certain .la file depends on and finally translates this into a package name and asks the packager to add this package name to "Requires".
This approach (the manual translation into a package name) is horribly broken because it cannot be undone automatically. Once the dependency disappears, the package name will remain in "Requires" until someone removes it manually.
Yes, ideally we somewhen would want to add these dependencies automatically. I'm not sure why we aren't doing that already, and could only speculate that it might have to do with lazy packagers including .la files in main rpms (not -devel or the like), which would generate silly install dependencies just because of these .la files (although never required at runtime then).
If it really has to work with package names, something like
Requires: %(rpm -qf --qf '%{NAME}\n' /usr/lib/libpopt.la)
can be used. But the filename-based dependency is the better option because libtool really needs the .la files with their absolute filename, it refuses to work if they were moved because it doesn't support the concept of a search path and the packagename-based approach doesn't reflect the fact that e.g. all legacy /opt/gnome .la files are broken now. The dependencies are still fulfilled, but the .la files don't work.
Yes, that's a problem, but the solution is unfortunately not filename-based deps. Or rather, it would be a solution, but you don't want to rely on filename deps too heavily. Reason is practicality of the dependency solver. If you use too many filename deps, you have to have a list of _all_ files provided by each rpm in a repository, instead of just the usual provides (pkgname, shared lib names, pseudo deps and the like). That set is huge, and our solver(s) is already bloated. There are ways working around this, at least somewhat, for instance when creating the repo, collect all Requires: filenames, and only store those into the provide->pkg map, but that would break already with multiple repos or 3rd party rpms. It's cleanest to either rely on pkg names, or (in case multiple packages might provide a service, or the pkg providing a service might change over time) invent pseudo provides (ala c_compiler).
There are good reasons why rpm doesn't translate "Requires: libc.so.6" into "Requires: glibc", the same rationale applies here.
That's a special case of (automatically generated) pseudo provides, namely shared lib dependecies. There are much fewer of those, than there are filenames. Ciao, Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Michael Matz píše v St 21. 02. 2007 v 20:00 +0100:
Hi,
On Wed, 21 Feb 2007, andreas.hanke@gmx-topmail.de wrote:
The problem is the way dependency information is extracted from .la files and transfered into the packages. The current approach seems to look at all .la files in the buildroot, then it tells the packager which packages provide the other .la files that a certain .la file depends on and finally translates this into a package name and asks the packager to add this package name to "Requires".
This approach (the manual translation into a package name) is horribly broken because it cannot be undone automatically. Once the dependency disappears, the package name will remain in "Requires" until someone removes it manually.
Yes, ideally we somewhen would want to add these dependencies automatically. I'm not sure why we aren't doing that already, and could only speculate that it might have to do with lazy packagers including .la files in main rpms (not -devel or the like), which would generate silly install dependencies just because of these .la files (although never required at runtime then).
I am an author of the current script. I see a big problem, that not all .la files are in -devel packages and you cannot add libtool dependencies to non -devel packages. So the check has to go recursively to the next -devel package. Another problem of my check was in .la files provided twice (mDNSResponder/avahi and fam/gamin). I guess it's not matter just now. You can use file Requires (e. g. Requires: /usr/lib/libfoo.la) only for packages, which has .la file. If the package has no .la file, you have to find .so file and then add it to the dependency chain. But it may be possible to assign files to packages automatically and then use package requires have a special black list, where you would prefer file requires (for .la files provided by more packages). -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wed, 21 Feb 2007, andreas.hanke@gmx-topmail.de wrote:
Hi,
Sure but this is the whole problem of almost all libtool discussions: People tend to generalize into one direction, skipping the other side of the story completely.
It seems that libtool is quite a religios product [...]
Sorry, this is absolutely not the point of my post and libtool isn't the only the problem, it's just a symptom.
I'm just trying to find out why various packages have so many and partially obsolete dependencies and found that .la files are 1 particular type of dependency generators, but there are others, e.g. seemingly harmless directories.
As long as .la files are present (and removing all of them would probably be overkill), they do carry dependency information that must somehow be used by the package manager because otherwise libtool won't be able to cope with the packages. So far there's no problem.
The problem is the way dependency information is extracted from .la files and transfered into the packages. The current approach seems to look at all .la files in the buildroot, then it tells the packager which packages provide the other .la files that a certain .la file depends on and finally translates this into a package name and asks the packager to add this package name to "Requires".
This approach (the manual translation into a package name) is horribly broken because it cannot be undone automatically. Once the dependency disappears, the package name will remain in "Requires" until someone removes it manually. This concept cannot work because nobody wants to constantly re-check the dependencies. This results in packages with excess dependencies.
There are various reasons why such a semi-automatically added dependency can become obsolete. A package might have stopped using a library or the library package might have been split, renamed or whatever.
A sane check that does not automatically add, but also automatically remove dependencies must work without the manual translation into a package name. This could be done by fully automatically adding
Requires: /usr/lib/libpopt.la
via a find-requires script instead of a brp script that prints "please add popt-devel to Requires". If the .la file later no longer references libpopt.la, the find-requires script will no longer automatically add this and the dependency just disappears without manual intervention.
But you are confusing Requires and BuildRequires here? While Requires can appear and disappear without too much collateral damage, BuildRequires that can no longer be satisfied (libpopt stops to ship libpopt.la) will result in a build failure and requires manual intervention - and in that case manual decision in whether now popt-devel is required. So, unfortunately a automated tool for reducing BuildRequires is hard because it actually needs to check if building is still possible. 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 Thu, Feb 22, 2007 at 10:08:07AM +0100, Richard Guenther wrote:
So, unfortunately a automated tool for reducing BuildRequires is hard because it actually needs to check if building is still possible.
If it was only that it wouldn't be that hard because you could actually test in an automated way whether a build succeeds or not. But it is actually harder because it would be needed to check whether it builds _and_ and result is what you wanted to have. For example a package that can be built with or without a specific optional support library with just less functionality without this support library would always tend to remove this dependency thus losing the (eventually) wanted functionality. You could also check this automatically but then every packager would need to write automatic tests for all such functionalities that can be checked by the build system. Unfortunately doing so is likely to be more work than just managing the dependencies manually. Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."
On Thu, 22 Feb 2007, Robert Schiele wrote:
On Thu, Feb 22, 2007 at 10:08:07AM +0100, Richard Guenther wrote:
So, unfortunately a automated tool for reducing BuildRequires is hard because it actually needs to check if building is still possible.
If it was only that it wouldn't be that hard because you could actually test in an automated way whether a build succeeds or not. But it is actually harder because it would be needed to check whether it builds _and_ and result is what you wanted to have. For example a package that can be built with or without a specific optional support library with just less functionality without this support library would always tend to remove this dependency thus losing the (eventually) wanted functionality.
Yes - I did this once semi-manually by ensuring the built packages is (nearly) bit-for-bit identical to the old one. I hope to get back to it at the point OBS supports bootstrapping Base:build. 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 Thu, Feb 22, 2007 at 10:55:28AM +0100, Richard Guenther wrote:
Yes - I did this once semi-manually by ensuring the built packages is (nearly) bit-for-bit identical to the old one. I hope to get back to it at the point OBS supports bootstrapping Base:build.
That functionality would definitely be useful for other purposes as well. I implemented result comparison for a different packaging system to drastically reduce workload of the build system. Having this feature one doesn't have to trigger the full transitive closure of all dependent packages if one of the root packages is changed but only the packages that directly depend on the changed package. In the next step only those packages rebuilt will trigger packages depending on them if the rebuild actually resulted in a change. For example if you change a package like bison and bison is used to build a tool that is used to build many other packages then without this a change to bison will trigger a rebuild of all packages depending on the other tool. If the check is implemented and the other tool does not change due to the bison change a huge number of packages can be just safely ignored on rebuilding. This does not only save much CPU power for building but can also reduce the number of versions of a package because you never keep packages with identical content. Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."
Hi,
But you are confusing Requires and BuildRequires here?
No, I am not confusing Requires and BuildRequires, I am talking about Requires of -devel packages and reduction of Requires, not BuildRequires. There is a connection between them because if A buildrequires B and B requires C, A effectively buildrequires C and changes to the relation between B and C can have an impact on A. But if A buildrequires C and silently relies on B satisfying that dependency, this does not look correct to me, it should buildrequire C directly. Reducing BuildRequires is certainly a nice thing, too, especially from a distributor's point of view, but I mostly care about Requires because this is what makes a user-visible installation large. Andreas Hanke -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, On Thu, 22 Feb 2007, Richard Guenther wrote:
But you are confusing Requires and BuildRequires here?
No, he's not confusing them. Our check-libtool-check script indeed gives the advise to manually add "X" to Requires: . That's his point. Once you do that manually, you loose the fact that you only added it because of an .la file, and what that need goes away, nobody is telling you anymore, that you now can remove it from Requires.
While Requires can appear and disappear without too much collateral damage, BuildRequires that can no longer be satisfied (libpopt stops to ship libpopt.la) will result in a build failure and requires manual intervention - and in that case manual decision in whether now popt-devel is required.
So, unfortunately a automated tool for reducing BuildRequires is hard because it actually needs to check if building is still possible.
I don't think he meant fiddling with BuildRequires. But let's suppose one would even do that, then it's still no problem: Situation is, that there's a BuildRequires, which by some measure is now unneeded, and we have a check for that unneededness. That check would run after the package is built (still with the superflous BuildRequires), then this BuildReq would be removed from the list. The next rebuild would not drag it in anymore, which is the right thing, because we already determined that it isn't needed anymore. Ciao, Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, just in case someone is still interested: Some packages have really creative and funny ways to defeat dependencies that are purely artificially generated by .la files. Bizarre example: http://svn.gnome.org/viewcvs/pango/trunk/sanitize-la.sh?revision=556&view=markup http://svn.gnome.org/viewcvs/pango/trunk/pango/Makefile.am?r1=551&r2=556 Andreas Hanke -- "Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ... Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi,
Some packages have really creative and funny ways to defeat dependencies that are purely artificially generated by .la files.
just before I forget, the explanation why they are doing that: It's _very much_ desired to not expose the rather fragile freetype ABI via pango, but the .la files do it anyway, even if static libraries are not even built. Unfortunately it doesn't actually work because nowadays, pango integrates with cairo and cairo.la has /usr/lib/libfreetype.la in its dependency_libs line. The result is very sad: # ldd -u -r /usr/bin/* 2>/dev/null | grep libfreetype\\.so\\.6 | wc -l 200 200 executables that possibly break if freetype breaks ABI although they don't have to. Andreas Hanke -- "Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ... Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, On Mon, 26 Feb 2007, andreas.hanke@gmx-topmail.de wrote:
Unfortunately it doesn't actually work because nowadays, pango integrates with cairo and cairo.la has /usr/lib/libfreetype.la in its dependency_libs line. The result is very sad:
# ldd -u -r /usr/bin/* 2>/dev/null | grep libfreetype\\.so\\.6 | wc -l 200
200 executables that possibly break if freetype breaks ABI although they don't have to.
While I agree with many of your points, this argumentation is flawed. If libabc is not directly used (i.e. in the deplist without a relocation into it) then any API change in libabc can't break the application. If it can break the application then by definition it's not unused. Additionally, if it breaks the API, then probably some of the libraries directly depending on it, which are used by the application (otherwise the useless dep wouldn't exist), will break too. That breakage will occur no matter if the useless deps are removed or not. Hence: removing the useless deps will not magically make API breakages go away. Ciao, Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi,
While I agree with many of your points, this argumentation is flawed. If libabc is not directly used (i.e. in the deplist without a relocation into it) then any API change in libabc can't break the application. If it can break the application then by definition it's not unused. Additionally, if it breaks the API, then probably some of the libraries directly depending on it, which are used by the application (otherwise the useless dep wouldn't exist), will break too. That breakage will occur no matter if the useless deps are removed or not.
Hence: removing the useless deps will not magically make API breakages go away.
What happens if libfreetype.so.6 becomes libfreetype.so.7 and is really not used? In such a case it can indeed break dependent packages unnecessarily. Or am I missing something? Andreas Hanke -- "Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ... Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Monday, 26. February 2007, andreas.hanke@gmx-topmail.de wrote:
What happens if libfreetype.so.6 becomes libfreetype.so.7 and is really not used? In such a case it can indeed break dependent packages unnecessarily.
Or am I missing something?
Yes, if it is not really used, then there is no dependent package. if there is a dependent package, then it is really used, and will break. Dirk --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Dirk Mueller wrote:
On Monday, 26. February 2007, andreas.hanke@gmx-topmail.de wrote:
What happens if libfreetype.so.6 becomes libfreetype.so.7 and is really not used? In such a case it can indeed break dependent packages unnecessarily.
Or am I missing something?
Yes, if it is not really used, then there is no dependent package. if there is a dependent package, then it is really used, and will break.
I think that Andreas ment by "really not used" that the app doesn't reference any symbols from the library (but is unnecessarily linked against it). Eg: $ gcc -o a1 hello.c $ gcc -lxyz -o a2 hello.c $ ./a1 hello! $ ./a2 hello! # rpm -e libxyz libxyz-devel $ ./a1 hello! $ ./a2 ./a2: error while loading shared libraries ... Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tuesday, 27. February 2007, Michal Marek wrote:
$ ./a2 ./a2: error while loading shared libraries ...
Well, if you link against it, then you want it to be used. Anyway, this has absolutely nothing to do with libtool. If you don't use -Wl,--as-needed, then you will get this behaviour. with -Wl,--as-needed it will work fine, because the linker drops unnecessary dependencies (increasing overall startup performance). Unfortunately, your depending libraries usually have to be fixed to work correctly with -Wl,--as-needed. I fixed a lot of instances of these kind of bugs for libraries that KDE depends but I totally ignored GNOME related bugs. Dirk --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, Feb 27, 2007 at 03:10:08PM +0100, Dirk Mueller wrote:
On Monday, 26. February 2007, andreas.hanke@gmx-topmail.de wrote:
What happens if libfreetype.so.6 becomes libfreetype.so.7 and is really not used? In such a case it can indeed break dependent packages unnecessarily.
Or am I missing something?
Yes, if it is not really used, then there is no dependent package. if there is a dependent package, then it is really used, and will break.
Although I am not really sure what you mean with your sentence, here an example that might show what Andreas is talking about: Consider two libraries alpha.so.1 and beta.so.1 and an application gamma. Now, given that gamma actually uses beta.so.1 and beta.so.1 uses alpha.so.1. In that situation gamma also uses alpha.so.1 but not in an explicit way because it does not call any symbol from the interface of alpha.so.1. Now we change the interface of alpha and thus get alpha.so.2. Obviously we have to rebuild beta to use alpha.so.2 but the interface of beta does not change and we still have beta.so.1. In that situation we _don't_ have to replace gamma with a new version because it could sill operate perfectly with (the new) beta.so.1 (and thus alpha.so.2). I hope this made this topic a bit more clear. Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."
Hi, On Mon, 26 Feb 2007, andreas.hanke@gmx-topmail.de wrote:
While I agree with many of your points, this argumentation is flawed. If libabc is not directly used (i.e. in the deplist without a relocation into it) then any API change in libabc can't break the application. If it can break the application then by definition it's not unused. Additionally, if it breaks the API, then probably some of the libraries directly depending on it, which are used by the application (otherwise the useless dep wouldn't exist), will break too. That breakage will occur no matter if the useless deps are removed or not.
Hence: removing the useless deps will not magically make API breakages go away.
What happens if libfreetype.so.6 becomes libfreetype.so.7 and is really not used? In such a case it can indeed break dependent packages unnecessarily.
Well, for libfreetype.so.6 to be in the deplist of application app, it had to be linked against some other library (let's say libbla.so), which itself links directly against libfreetype.so.6 and really uses it. If libfreetype.so.6 doesn't exist anymore then that library will break, no matter if app links against libfreetype.so.6 or not. As libbla.so really uses that library it's also no unneeded direct dependency, so you have to rebuild something anyway (libbla.so in this case). So, removing unneeded direct dependencies will not solve that problem at all. What it will do, though, is that less stuff has to be rebuilt. Ciao, Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
andreas.hanke@gmx-topmail.de writes:
Hi,
I just had a look on popt (which packages it has a dependency on, which packages depend on it) and was again astonished by the impact its .la file (/usr/lib/libpopt.la) has.
Only very few packages really require popt (rpm and libgnome, to name a few). But the .la file infects all packages above them in the dependency chain so that they will also depend on popt even if they don't have to. This happens to affect mostly GNOME packages...
The following packages currently have dependencies on popt-devel although they don't #include <popt.h>:
gnome-bluetooth-devel gstreamer010-devel libgnomeui-devel libzypp-devel orbit2-devel
Why? Because of a libtool dependency check that completely ignores the fact that these dependencies are generated by the .la files. The .la files are not storing actual dependencies, they are generating new ones.
Just as an example:
# grep popt /usr/lib/libzypp.la dependency_libs=' /usr/lib/libxml2.la -lcurl /usr/lib/libidn.la -lssl -lcrypto /usr/lib/librpm.la /usr/lib/librpmdb.la /usr/lib/librpmio.la -ldl -lpthread -lz -lbz2 /usr/lib/libpopt.la /usr/lib/libgobject-2.0.la /usr/lib/libdbus-glib-1.la /usr/lib/libgobject-2.0.la /usr/lib/libglib-2.0.la -lnsl /usr/lib/libglib-2.0.la -lrt /usr/lib/libhal-storage.la /usr/lib/libhal.la /usr/lib/libhal.la /usr/lib/libdbus-1.la /usr/lib/libdbus-1.la -lboost_regex -lboost_filesystem -lutil'
But:
# rpm -ql libzypp-devel | xargs grep popt\\.h (no matches) # ldd -u -r /usr/bin/zypper Unused direct dependencies: /usr/lib/libpopt.so.0
In fact there is no need to link zypp-based programs to popt because zypp does not expose it, but libtool adds it anyway just because /usr/lib/librpm.la has it. In short, .la files always contain as many dependencies as possible. These dependencies were not present if the packages were not installing their .la files.
Another flaw with this approach is that it's a one-way thing. Dependencies are added if needed, but never removed.
Example: Some time ago, a package really used popt, so the check told you to add "Requires: popt-devel" to the -devel package. Later, the package stops using popt, but the check doesn't notice that and the dependency will stay forevermore. This is especially annoying if the authors of this package spent resources into getting rid of that dependency.
# rpm -ql libnotify-devel | grep \\.la /usr/lib/libnotify.la # grep popt /usr/lib/libnotify.la (no matches) # rpm -ql libnotify-devel | xargs grep popt\\.h (no matches)
What should we do? Remove popt.la from the package? But what is the general solution?
And now the worst thing:
# rpm -ql libnotify | xargs grep popt /usr/share/doc/packages/libnotify/ChangeLog: - Patch by M.S. to switch notify-send to use GOption instead of popt, /usr/share/doc/packages/libnotify/NEWS: * Patch by M.S. to switch notify-send to use GOption instead of popt,
But it happily requires popt-devel anyway:
# rpm -q --requires libnotify-devel | grep popt popt-devel
There is no way to get rid of these again other than manually looking at the packages and manually trying to find out why the dependencies have been added and if they are still needed. ARGH!
I just fixed this one single package, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Tue, 20 Feb 2007, Andreas Jaeger wrote:
andreas.hanke@gmx-topmail.de writes:
Example: Some time ago, a package really used popt, so the check told you to add "Requires: popt-devel" to the -devel package. Later, the package stops using popt, but the check doesn't notice that and the dependency will stay forevermore. This is especially annoying if the authors of this package spent resources into getting rid of that dependency.
# rpm -ql libnotify-devel | grep \\.la /usr/lib/libnotify.la # grep popt /usr/lib/libnotify.la (no matches) # rpm -ql libnotify-devel | xargs grep popt\\.h (no matches)
What should we do? Remove popt.la from the package?
But what is the general solution?
Most .la files packaged in -devel packages can be removed in case static linking is not required. .la files necessary at runtime to make ltdlopen work should be packaged in the regular library package. Now, whether we should stop packaging static libraries for each and every library we have is another (valid) question. 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
[Think twice before replying to a list. Think twice before replying to a list. ... Sorry Richard :-/] Richard Guenther wrote:
Now, whether we should stop packaging static libraries for each and every library we have is another (valid) question.
Excluding static libs would be IMHO a good idea at least for libraries that handle untrusted data and have security updates sometimes (eg.: openssl). Or splitting the *.a files to extra subpackages and banning these in BuildRequires. Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tuesday, 20. February 2007 13:40, Richard Guenther wrote:
Most .la files packaged in -devel packages can be removed in case static linking is not required. .la files necessary at runtime to make ltdlopen work should be packaged in the regular library package.
in case of libpopt (which for very strange reasons is built by rpm), the .la file can just be deleted, because it doesn't have additional dependencies.
Now, whether we should stop packaging static libraries for each and every library we have is another (valid) question.
static libs should at least be in the -devel subpackage and removed if it is a library that likely suffers from security vulnerabilities (to avoid that the code is statically linked into some other package). Dirk --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, 20 Feb 2007, Dirk Mueller wrote:
On Tuesday, 20. February 2007 13:40, Richard Guenther wrote:
Most .la files packaged in -devel packages can be removed in case static linking is not required. .la files necessary at runtime to make ltdlopen work should be packaged in the regular library package.
in case of libpopt (which for very strange reasons is built by rpm), the .la file can just be deleted, because it doesn't have additional dependencies.
Indeed.
Now, whether we should stop packaging static libraries for each and every library we have is another (valid) question.
static libs should at least be in the -devel subpackage and removed if it is a library that likely suffers from security vulnerabilities (to avoid that the code is statically linked into some other package).
Well, I doubt we for example ever will need /usr/lib64/libxfce4mcs-client.a which is unfortunately in libxfce4mcs-4.2.3-29 and not a -devel package for example. Care to write a brp-check for .a and .so files not in a -devel 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
Richard Guenther <rguenther@suse.de> writes:
On Tue, 20 Feb 2007, Dirk Mueller wrote:
On Tuesday, 20. February 2007 13:40, Richard Guenther wrote:
Most .la files packaged in -devel packages can be removed in case static linking is not required. .la files necessary at runtime to make ltdlopen work should be packaged in the regular library package.
in case of libpopt (which for very strange reasons is built by rpm), the .la file can just be deleted, because it doesn't have additional dependencies.
Indeed.
So, Dirk and Richard: will either of you do it, please?
Now, whether we should stop packaging static libraries for each and every library we have is another (valid) question.
static libs should at least be in the -devel subpackage and removed if it is a library that likely suffers from security vulnerabilities (to avoid that the code is statically linked into some other package).
Well, I doubt we for example ever will need
/usr/lib64/libxfce4mcs-client.a
which is unfortunately in libxfce4mcs-4.2.3-29 and not a -devel package for example. Care to write a brp-check for .a and .so files not in a -devel package?
Yes, I agree, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Tuesday, 20. February 2007 14:53, Richard Guenther wrote:
/usr/lib64/libxfce4mcs-client.a
Well, tell the xfce maintainer ;)
which is unfortunately in libxfce4mcs-4.2.3-29 and not a -devel package for example. Care to write a brp-check for .a and .so files not in a -devel package?
Can't be written as a brp check, because at the time they're running there is no package yet, so you don't know in which package it will end up. A rpmlint check for this would be accepted however (and I think it exists already). Dirk --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, 20 Feb 2007, Dirk Mueller wrote:
On Tuesday, 20. February 2007 14:53, Richard Guenther wrote:
/usr/lib64/libxfce4mcs-client.a
Well, tell the xfce maintainer ;)
Seems to be fixed in Factory (I quoted from an installed 10.2 system). Still the .so links are not in the -devel 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
Hi, On Tue, 20 Feb 2007, Richard Guenther wrote:
/usr/lib64/libxfce4mcs-client.a
Well, tell the xfce maintainer ;)
Seems to be fixed in Factory (I quoted from an installed 10.2 system). Still the .so links are not in the -devel package.
Reminds me of something which we eventually want to have (and which I had on my disc since some time): A packaging policy for libraries. I've started to cobble up something, though I find my language a bit awkward :-/ Anyway, the ideas should become clear. I haven't yet read the debian library policy, but it certainly is inspired by it (via conversation with debian guys). Probably their policy contains much more interesting stuff, which might become usable. But let's start with something small, and discuss about it. Ciao, Michael. Definitions lib$NAME.so.* - a shared library, programs can depend on them, usually two files exist: lib$NAME.so.$MAJOR lib$NAME.so.$MAJOR.$MINOR.$MICRO lib$NAME.so - file used by link editor (ld) to build executable, usually softlink to the shared library file Goal Enable running old applications needing old shared libraries, without recompilation (i.e. by merely copying over some old binary rpms and installing them). Library policy * Shared libs are to be packaged into rpms whose name is "lib" + $NAME + $NUM. * There is no package containing lib*.so.* files which is not named lib$NAME$NUM.rpm. * Packages named lib* contain only files named lib*.so.* (no headers, no *.so files, no config files, nothing else). * $NUM contains only decimal digits. * $NUM increases strictly with at least the SO version of the contained shared libs. Ideally it corresponds with either the upstream package version or the SO version. Example: libfoo.so.1 is packaged in libfoo1.rpm. Or libbar.so.3, a part of the program suite PLONK 4.1, would be packaged into libplonk41.rpm. * All packages named lib* end with $NUM. * Files needed to develop programs using shared libraries contained in lib$NAME$NUM.rpm are packaged in lib$NAME-devel.rpm. [??? do we really want to remove $NUM from the -devel rpm?] Those files include lib*.so, lib*.la and all headers. Optionally those files can also be placed in $NAME.rpm, in the case that it also comes with other tools or documentation. But _if_ there is a *-devel.rpm package then it contains all lib*.{so,la} and headers. Rationale That scheme makes it possible to install and use multiple shared libraries of the same base name, but different so-version (e.g. of older distribution in case there are programs requiring them). A discriminator needs to be part of the rpm name, as otherwise the update stack will be confused, and using some monotonically increasing number as that makes sense. A strict structure on rpm names will also help those writing quick&dirty tools.
From that follows that only files should be included therein, which aren't generating file conflicts later if installed together with another libbla* rpm. Hence only lib*.so.* files are allowed in them. To ensure that no shared libraries creep in which aren't handled that way we disallow them to be in any package not named via these rules.
Effectively that creates a partition of all files into shared libs and others, and makes sure that no rpm contains files from both partitions. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, 20 Feb 2007, Michael Matz wrote:
Hi,
On Tue, 20 Feb 2007, Richard Guenther wrote:
/usr/lib64/libxfce4mcs-client.a
Well, tell the xfce maintainer ;)
Seems to be fixed in Factory (I quoted from an installed 10.2 system). Still the .so links are not in the -devel package.
Reminds me of something which we eventually want to have (and which I had on my disc since some time): A packaging policy for libraries. I've started to cobble up something, though I find my language a bit awkward :-/ Anyway, the ideas should become clear.
I haven't yet read the debian library policy, but it certainly is inspired by it (via conversation with debian guys). Probably their policy contains much more interesting stuff, which might become usable. But let's start with something small, and discuss about it.
Ciao, Michael.
Definitions
lib$NAME.so.* - a shared library, programs can depend on them, usually two files exist: lib$NAME.so.$MAJOR lib$NAME.so.$MAJOR.$MINOR.$MICRO lib$NAME.so - file used by link editor (ld) to build executable, usually softlink to the shared library file
Goal
Enable running old applications needing old shared libraries, without recompilation (i.e. by merely copying over some old binary rpms and installing them).
Library policy
* Shared libs are to be packaged into rpms whose name is "lib" + $NAME + $NUM. * There is no package containing lib*.so.* files which is not named lib$NAME$NUM.rpm. * Packages named lib* contain only files named lib*.so.* (no headers, no *.so files, no config files, nothing else).
* $NUM contains only decimal digits. * $NUM increases strictly with at least the SO version of the contained shared libs.
Ideally it corresponds with either the upstream package version or the SO version. Example: libfoo.so.1 is packaged in libfoo1.rpm. Or libbar.so.3, a part of the program suite PLONK 4.1, would be packaged into libplonk41.rpm.
The latter sounds inconsistent. Shouldn't it be named libbar41.rpm? I would add * lib$NAME$NUM.rpm either contains exactly one shared library named lib$NAME.so.* or it contains multiple shared libraries. * If lib$NAME$NUM.rpm may only contain multiple shared libraries if the SO versions of all of them change at the same time always. For convenience library packages should be split if not a dependency on one shared library automatically creates a dependency on all other shared library in the package. * If lib$NAME$NUM.rpm contains multiple shared libraries $NAME should match the package name. For example if the program blorf.rpm has libfoo.so.* and libbar.so.* the library package shall be named libblorf$NUM.rpm
* All packages named lib* end with $NUM.
Or with -devel.
* Files needed to develop programs using shared libraries contained in lib$NAME$NUM.rpm are packaged in lib$NAME-devel.rpm. [??? do we really want to remove $NUM from the -devel rpm?]
That depends on whether multiple -devel versions can be installed in parallel. Usually this will result in file conflicts with includes or documentation, so the recommended way is to only have the latest-and-greatest as lib$NAME-devel. Exceptions allowed.
Those files include lib*.so, lib*.la and all headers. Optionally those files can also be placed in $NAME.rpm, in the case that it also comes with other tools or documentation. But _if_ there is a *-devel.rpm package then it contains all lib*.{so,la} and headers.
Rationale
That scheme makes it possible to install and use multiple shared libraries of the same base name, but different so-version (e.g. of older distribution in case there are programs requiring them). A discriminator needs to be part of the rpm name, as otherwise the update stack will be confused, and using some monotonically increasing number as that makes sense. A strict structure on rpm names will also help those writing quick&dirty tools.
From that follows that only files should be included therein, which aren't generating file conflicts later if installed together with another libbla* rpm. Hence only lib*.so.* files are allowed in them. To ensure that no shared libraries creep in which aren't handled that way we disallow them to be in any package not named via these rules.
Effectively that creates a partition of all files into shared libs and others, and makes sure that no rpm contains files from both partitions.
The policy currently misses to talk about static libraries, -fpic issues and documentation subpackages. A section on ABI compatibility and SO versions would be nice. I recommend to have a look at http://www.debian.org/doc/debian-policy/ch-sharedlibs.html and http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html also the following is a nice checklist for updating packages when a SO version change is involved. http://wiki.debian.org/TransitionBestPractices 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 Tue, 20 Feb 2007, Richard Guenther wrote:
* $NUM contains only decimal digits. * $NUM increases strictly with at least the SO version of the contained shared libs.
Ideally it corresponds with either the upstream package version or the SO version. Example: libfoo.so.1 is packaged in libfoo1.rpm. Or libbar.so.3, a part of the program suite PLONK 4.1, would be packaged into libplonk41.rpm.
The latter sounds inconsistent. Shouldn't it be named libbar41.rpm?
That was to demonstrate the possibility that one rpm can contain multiple shared libs belonging to one program suite PLONK, so the rpm name would be something with "plonk". I just didn't make myself clear :)
I would add
* lib$NAME$NUM.rpm either contains exactly one shared library named lib$NAME.so.* or it contains multiple shared libraries.
* If lib$NAME$NUM.rpm may only contain multiple shared libraries if the SO versions of all of them change at the same time always. For convenience library packages should be split if not a dependency on one shared library automatically creates a dependency on all other shared library in the package.
I'm not sure about the convenience part. One model of mind for "package containing many shared libs" is kdelibs. Using just one of those shared libs will not necessarily also make the program depend on _all_ other shared libs therein, but only on some. But it still is the case that all SO versions will increase in lockstep, so it's okay to have just one container RPM. OTOH if someone isn't sure about the future it makes sense to prefer split shared library packages. Hmm.
* If lib$NAME$NUM.rpm contains multiple shared libraries $NAME should match the package name. For example if the program blorf.rpm has libfoo.so.* and libbar.so.* the library package shall be named libblorf$NUM.rpm
Yes, that's what I wanted to say, thanks :)
* All packages named lib* end with $NUM.
Or with -devel.
Yeah, I noticed that ommission. But if we mention -devel, then also -debuginfo and the like. Perhaps * All unsuffixed packages named lib* end with $NUM. Common suffixes include e.g. -devel or -debuginfo. ?
* Files needed to develop programs using shared libraries contained in lib$NAME$NUM.rpm are packaged in lib$NAME-devel.rpm. [??? do we really want to remove $NUM from the -devel rpm?]
That depends on whether multiple -devel versions can be installed in parallel. Usually this will result in file conflicts with includes or documentation, so the recommended way is to only have the latest-and-greatest as lib$NAME-devel. Exceptions allowed.
Okay.
The policy currently misses to talk about static libraries, -fpic issues and documentation subpackages. A section on ABI compatibility and SO versions would be nice.
Agreed.
http://www.debian.org/doc/debian-policy/ch-sharedlibs.html http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html http://wiki.debian.org/TransitionBestPractices
Thanks. Ciao, Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, 20 Feb 2007, Michael Matz wrote:
Hi,
On Tue, 20 Feb 2007, Richard Guenther wrote:
I would add
* lib$NAME$NUM.rpm either contains exactly one shared library named lib$NAME.so.* or it contains multiple shared libraries.
* If lib$NAME$NUM.rpm may only contain multiple shared libraries if the SO versions of all of them change at the same time always. For convenience library packages should be split if not a dependency on one shared library automatically creates a dependency on all other shared library in the package.
I'm not sure about the convenience part. One model of mind for "package containing many shared libs" is kdelibs. Using just one of those shared libs will not necessarily also make the program depend on _all_ other shared libs therein, but only on some. But it still is the case that all SO versions will increase in lockstep, so it's okay to have just one container RPM.
OTOH if someone isn't sure about the future it makes sense to prefer split shared library packages. Hmm.
It's also about reducing installed size. One might for example use some convenient library from kdelibs together with Qt for a small application. If that is the only kdelibs dependecy it would be nice to not pull in all of kdelibs to keep the install footprint of virtual machines small. But we should definitely add 'exceptions are allowed' ;) Another thing is if you have a program that comes with a shared library but is its sole user. In this case the shared libraries should go in a subdirectory of /usr/%{_lib} named after the package and it may be packaged within the program rpm. No -devel or .a, .so file packaging should be allowed in this case.
* All packages named lib* end with $NUM.
Or with -devel.
Yeah, I noticed that ommission. But if we mention -devel, then also -debuginfo and the like. Perhaps
* All unsuffixed packages named lib* end with $NUM. Common suffixes include e.g. -devel or -debuginfo.
That sounds good. 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
* Richard Guenther (rguenther@suse.de) [20070220 13:37]:
.la files necessary at runtime to make ltdlopen work should be packaged in the regular library package.
AFAIR, ltdlopen happily works without .la files. Philipp --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, On Fri, 23 Feb 2007, Philipp Thomas wrote:
* Richard Guenther (rguenther@suse.de) [20070220 13:37]:
.la files necessary at runtime to make ltdlopen work should be packaged in the regular library package.
AFAIR, ltdlopen happily works without .la files.
Not really. If you call it with lt_dlopen("bla.la") it really only looks for the .la file. You can use lt_dlopenext("bla") which tries to automatically add several extensions. And then there are some packages (libgcj for instance), which try to find the .la find by hand, before using ltdlopen, and that breaks in hard to find ways then :-( Ciao, Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
* Michael Matz (matz@suse.de) [20070223 16:37]:
And then there are some packages (libgcj for instance), which try to find the .la find by hand, before using ltdlopen, and that breaks in hard to find ways then :-(
Oh, wonderful :-( That's one class of bugs I don't want to have to hunt down. Philipp --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (10)
-
Andreas Jaeger -
andreas.hanke＠gmx-topmail.de -
Dirk Mueller -
Dirk Mueller -
Michael Matz -
Michal Marek -
Philipp Thomas -
Richard Guenther -
Robert Schiele -
Stanislav Brabec