On Mon, Mar 19, 2012 at 17:26:04 -0500, Jonathan Nieder wrote: > > These dependencies must be added to the binary > > package when it is built, since they may change > > This means packages must not hard-code library dependencies. It > also seems like good policy, but I suspect it would render packages > such as chromium that use dlopen() and hard-code the corresponding > library name in dependencies RC-buggy. > They're already broken. > What about libraries like glib (assuming one only uses old symbols) > that are never supposed to change soname? > What about them? > [...] > > To allow these dependencies to be constructed, shared libraries > > must provide either a <file>symbols</file> file or > > a <file>shlibs</file> file, which provide information on the > > package dependencies required to ensure the presence of this > > library. > > Subject/verb agreement: s/provide/provides/ > > Clarity: s/this library/interfaces provided by this library/ > > > <p> > > These two mechanisms differ in the degree of detail that they > > provide. A <file>symbols</file> file documents every symbol > > that is part of the library ABI and, for each, the version of > > the package in which it was introduced. > > Maybe, since minimal-version is not always the version in which the > symbol was introduced: > > and, for each, a minimal version of the library needed to use > that symbol, which is typically the version of the package in > which it was introduced. > > [...] > > <file>shlibs<file> files also have a flawed representation of > > library SONAMEs, making it difficult to use <file>shlibs</file> > > files in some unusual corner cases. > > I'm not sure what this passage is referring to. Can you say more? > (Maybe in a footnote.) > libfooN.shlibs says 'libfoo N' not the actual SONAME, so if the SONAME doesn't match one of the two expected formats (libfoo-N.so or libfoo.so.N) it can't be represented. > [...] > > udebs > > must also use <file>shlibs</file>, since the udeb infrastructure > > does not use <file>symbols</file>. > > To avoid confusion it might be worth forbidding symbols files in > udebs, or at least symbols files without a corresponding shlibs file > accompanying them. > That makes no sense. udebs don't have those files, when building an udeb the dependency information is read from the shlibs files of the debs corresponding to the libraries you depend on. > [...] > > If you have > > multiple binary packages, you will need to > > call <prgn>dpkg-shlibdeps</prgn> on each one which contains > > compiled libraries or binaries, using the <tt>-T</tt> option > > to the <tt>dpkg</tt> utilities to specify a > > different <file>substvars</file> file for each binary > > package.<footnote> > > An alternative is to clear substvars between builds of different > binary packages. > Who does that? I don't think it's necessary to document all the twisted ways to make things not break. > [...] > > loads <tt>libbar</tt>. A package should depend on the > > libraries it directly uses, but not the libraries it > > indirectly uses. > > Pedantry: what if my package uses the same library both directly and > indirectly? "but not the libraries it only uses indirectly" would > avoid that question. > > > There are two types of ABI changes: ones that are > > backward-compatible and ones that are not. An ABI change is > > backward-compatible if any binary was linked with the previous > > version of the shared library will still work correctly with > > the new version of the shared library. Adding new symbols to > > the shared library is a backward-compatible change. Removing > > symbols from the shared library is not. > > If I remove a symbol that was documented to be private or change > the behavior of a function when given invalid arguments, is that a > backward-compatible change? > > If I add change the implementation in such a way that the library > becomes so large that some large programs cannot use it any more, is > that a backward-incompatible change? > I'm not sure policy should go into such details. And anyway, that's answered by the previous sentence (an incompatible change is one that breaks reverse deps). The last two are simple examples. Cheers, Julien
Attachment:
signature.asc
Description: Digital signature