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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
