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

Re: Dependencies on shared libs, take 2



Loïc Minier <lool@dooz.org> writes:
> On Mon, Jun 04, 2007, Raphael Hertzog wrote:
>> Library maintainers are supposed to maintain the *.symbols file.  For
>> this, they have to create files "debian/<package>.symbols.<arch>"
>> (dpkg-gensymbols will try too fallback to "debian/symbols.<arch>",
>> "debian/<package>.symbols" and "debian/symbols"). They are
>> required to provide the minimal version (as used in the dependency
>> generated) associated to each symbol.
>  While this seemed sensible on my first read, I think it's a burden to
>  effectively maintain multiple *.symbols.* files for multiple arches or
>  packages (for example flavors of the same library) with only small
>  differences between the lists.

Showers need to be good for something, so I thought about this today in
the shower and wondered why the arch files couldn't be treated as simple
override files. I expect that most libraries keep the same version data
for (almost) all archs in sync, so it seems to be sensible to simply use
a debian/$package.symbols file and only override the information for the
few needed symbols in a debian/$package.symbols.$arch file. 

The current codebase would only need a few changes (loading
debian/symbols, then loading debian/symbols.$arch into the same hash).

This doesn't reduce the work needed for various flavours of the same
lib, so an include statement would perhaps still be a good idea. Or
simply preprocess all files with cpp :-)

Marc
-- 
Fachbegriffe der Informatik - Einfach erklärt
70: It is essential that implementations by different vendors interoperate.
       Unsere proprietären Basteleien dokumentieren wir gar nicht erst.
       (Sven Türpe)

Attachment: pgp2qU1zvMV6g.pgp
Description: PGP signature


Reply to: