On Wed, Jun 06, 2007 at 09:53:22AM +0200, Raphael Hertzog wrote: > 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 ? 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. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]