Re: Dependencies on shared libs, take 2
On Mon, Jun 04, 2007, Raphael Hertzog wrote:
> Library maintainers are supposed to maintain the *.symbols file. For
> this, they have to create files "debian/<package>.symbols.<arch>"
> (dpkg-gensymbols will try too fallback to "debian/symbols.<arch>",
> "debian/<package>.symbols" and "debian/symbols"). They are
> required to provide the minimal version (as used in the dependency
> generated) associated to each symbol.
While this seemed sensible on my first read, I think it's a burden to
effectively maintain multiple *.symbols.* files for multiple arches or
packages (for example flavors of the same library) with only small
differences between the lists.
I was about to suggest adding a way to share such lists, for example
an include mechanism, but all of this seems to be at the wrong level:
I think dpkg-* tools should only be concerned about debian/symbols or
DEBIAN/symbols, and leave handling of architecture / package specific
overrides to higher level stacks such as debhelper.
I suppose maintainers will resort to the same file generation tricks
that they already use to share file lists, shlibs information or
whatever, and CDBS will provide new hooks for overrides as well
Quid of udebs? Are these affected by the changes?
> Since symbol information is integrated in the package itself, a
> "debdiff --controlfiles ALL" would directly show if a package
> introduces new symbols or removes existing ones.
That a cool feature by itself, it means I will be able to review symbol
changes without resorting to custom scripts or manual diffs!
--
Loïc Minier
Reply to: