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 :

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

[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

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

Richard Guenther 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 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 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 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 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 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 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,

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

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 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, 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 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

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

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, 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

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, 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

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

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