Re: Dependencies on shared libs, take 2
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
GLIBC_2.0@GLIBC_2.0 libc6 2.3.6.ds1-13
_Exit@GLIBC_2.1.1 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/
Reply to: