Hi,
On Wed, 21 Feb 2007, [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
