Re: Dependencies on shared libs, take 2
On Tue, 05 Jun 2007, Joey Hess wrote:
> Note that policy doesn't fully document[1] the current shlibs format,
> which is:
>
> [package-type:] library-name soname-version-number dependencies...
>
> It seems that this could be extended to include symbol information:
>
> [package-type:] library-name soname-version-number dependencies...
> [symbol dependencies...]
> [...]
Currently my code uses shlibs as fallback if there's no symbols file. I
believe it simplifies the future integration of the tool in the build
system.
For me the only significant advantage of this proposed format is that it
offers the possibility to add additional automatic dependencies at the
package level and not only at the symbol level.
Joey, how would you integrate this new scheme if I decided to reuse the
shlibs file as you proposed?
Currently my plan was simply to have people add one (or more) calls
to dpkg-gensymbols in the build process (between dh_installdeb
and dh_shlibdeps, and possibly integrated within dh_makeshlibs too).
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.
How can we make sure that this second step actually happens in the build
process? Would you accept to modifiy dh_installdeb for this?
Hum... it doesn't sound so complicated after all. What do others think?
> Like the package-type extension, this extra information will be
> transparently ignored by old versions of dpkg-shlibdeps. Besides being
> slightly more compact[2], it also has benefit of allowing inclusion of
> differing symbol information for udebs, if it ever becomes useful to do
> so.
FWIW, I find the current mix of udeb and deb in the same shlibs file
somewhat inelegant. I'd rather have used a second dedicated file that
would have followed the same initial format.
> [2] Would it be worthwhile to support multiple symbols on one line to
> save even more space?
> symbol [symbol...] dependencies...
No. Having one symbol per line makes the file easily diffable and this is
important since maintainers will have to maintain those files. And as I
explained such a diff could be included in a failed build logs in case we
have differences between what's submitted and what's detected at build
time.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Reply to: