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