Re: Dependencies on shared libs, take 2
On Wed, Jun 06, 2007 at 09:53:22AM +0200, Raphael Hertzog wrote:
> 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 ?
FWIW, in the prototyping I did in the unixodbc package I made the symbol
version and the symbol name two separate fields separated by whitespace,
because this made it easier to generate files of this format with objdump -T
and a little bit of shell. Dunno if you consider that a relevant advantage,
but it does seem unnecessary to me to store the symbol names in a different
format than that returned by objdump (given that you need objdump, not nm,
to get the version of any undefined symbols referenced by an object).
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Reply to: