[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: