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