On Tue, 05 Jun 2007, Joey Hess wrote: > It seems that this could be extended to include symbol information: > > [package-type:] library-name soname-version-number dependencies... > [symbol dependencies...] > [...] > > Like the package-type extension, this extra information will be > transparently ignored by old versions of dpkg-shlibdeps.
I double-checked this and no, it's not the case. Extract from dpkg-shlibdeps: while (<SLF>) { s/\s*\n$//; next if m/^\#/; if (!m/^\s*(?:(\S+):\s+)?(\S+)\s+(\S+)/) { &warn(sprintf(_g("shared libs info file \`%s' line %d: bad line \`%s'"), $fn, $., $_)); next; } [...] } What you propose would look like: libc 6 [EMAIL PROTECTED] libc6 2.3.6.ds1-13 [EMAIL PROTECTED] libc6 2.3.6.ds1-13 Because of the "^\s*" you can't use starting spaces as a differentiating factor. The lines with symbols would still match and be considered as usual shlibs line. Your format can still makes sense however... but it must be a separate file. And since it's a separate file anyway, I don't have to follow the original shlibs format. In that case I'd rather put the soname directly instead of splitting it in library name and version. It would give: [package type: ]<soname> <package-providing-it> <package-wide-additional dependencies> <symbol> <minversion> [...] Another benefit is that we can get rid of the additionnal dependencies at the symbol level which are of no practical use anyway. We could however add an architecture restriction list (similar to what we have in build dependencies) that would be used to filter out some symbols when installing the file in the .deb. How does that sound ? 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]