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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
