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).
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: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org