Re: Dependencies on shared libs, take 2

[Andreas Barth <aba@not.so.argh.org>]

* Raphael Hertzog (hertzog@debian.org) [070606 14:03]:
> On Wed, 06 Jun 2007, Steve Langasek wrote:
> > On Wed, Jun 06, 2007 at 09:15:02AM +0200, Raphael Hertzog wrote:
> > > Now, if we have people store symbols in shlibs file, it means that
> > > dh_installdeb would install the shlibs file with symbols. That could be
> > > almost enough except that we really want a check that the information
> > > stored in those files matches the reality so we need to call
> > > dpkg-gensymbols either to update the file with real symbol information or
> > > at least to verify it and fail it it doesn't match.
> > 
> > Can you clarify what you mean by "update the file with real symbol
> > information"?  If the real lib doesn't match, how do you plan to achieve
> > this?
> 
> The real lib has precedence over the provided symbols file.
> - any new symbol is added and marked with mininal version being the current
>   version of the package
> - a symbol that disappeared is marked as deprecated. Currently it
>   comments it out in the file like this:
> #DEPRECATED: 2.5-9#ld-linux.so.2 _dl_out_of_memory@GLIBC_PRIVATE libc6 2.3.6.ds1-13

symbols MUST NEVER disappear!


> The information generated is saved in the "DEBIAN/symbols" file inside the
> package. This information can then be auto-extracted on one of our servers
> and made available to developers so that they can update their
> debian/*.symbols.* files.

I really think this is broken - the developer should be able to extract
this information without a big central server.

IMHO it is better to just fail this build, hand the developer the
missing information, and let him update the source package.



Cheers,
Andi