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