* Thomas Viehmann wrote: > Sebastian Ley wrote: > > To be able to use dh_shlibdeps anyway each library module should > > add a "Provides:" line, providing the name of the corresponding > > deb package of the library. I.e. libc6-udeb should provide libc6. > > I do have the impression that most shlibs files are versioned > dependencies. It is my understanding that the debian-installer > simply ignores them so that a simple provides is > sufficient. However, this is a difference to conventional deb > packages, for which it is (due to lack of versioned provides) > currently impossible to satisfy such a versioned dependency (AFAIK).
I do not know if I understood your point: udpkg currently ignores versioned dependencies, so for the installer it will be ok to provide an unversioned Provide and satisfy it with a versioned Depends. This most likely won't work for dpkg, but since udebs shall never be installed on real debian systems dpkg should never see them. > > Since the development link is identically to the development link > > in libfoo-dev, the library and the links should be installed in a > > subdirectory of /usr/lib, e.g. /usr/lib/libfoo-udeb. > > If you want to make this a standard, you should IMHO be more precise > about the subdirectory: First it should probably not be "e.g.", but > rather "the subdirectory should be named..." and then you might want > to specify the exact derivation of the name. (Is it the derived from > the library soname, the package name, should the soversion be used? > Sometimes, those the package name and the library name differ, > e.g. slang1a). Yes, you are right, being more specific would help other developers a lot. In this case I would suggest to use the udeb name as the name for the subdirectory. However perhaps a still better idea is to use one single directory for all udeb-dev packages, see below. > Also, one of the things I like about the Junichi Uekawa's > libpkg-guide is that it tries to explain the rationale. (At least I > myself try to learn by imagining what would go wrong unless one does > the right thing.) I will try to improve that before commiting it. > In this particular case, it might be interesting to know what the > advantage of a subdirectory for each udeb library over a > /usr/lib/udeblib is. This is a good one, I had the same idea but could not decide which was better. Thinking again about this, I favor the idea, to have a single subdir where all udeb libraries go in. You can just use LDFLAGS="-L/usr/lib/udeblib" and you include them all at once. If there are no objections I would like to change this in the docs and I would like to hear suggestions for the subdir. Is "udeblib" fine? > Also, what happens with api incompatibilities? Is it entirely > impossible to have different include libraries for the "real" lib > debs and the udeb versions? I have to admit that I just don't know. The libraries I have been working on just copied their headers. If there are other libraries, that generate different headers based upon compile options we have to take care of it: 1) forbid changing compile option so that api breaks OR 2) let udeb-dev packages install their headers into a subdir of /usr/include, i.e. udebinclude... Does anyone know more about this? > Your guide has been very interesting reading. Thank you. Thank you for your comments, they have been very resourceful. Sebastian -- PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key Fingerprint: A46A 753F AEDC 2C01 BE6E F6DB 97E0 3309 9FD6 E3E6 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
