Hi. I don't know if how general the audience you're aiming at is. I'm not an expert, but rather a casual user who recently built a library udeb for his private purposes (it was slang1a for nano, I used libpango and others as examples and it worked in the end). Most of the problems I ran into are commented in you're guide, however I believe that some questions might be worth being more clear about. 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). [...] > Since modules should not be installed on normal systems there is need > for a deb package providing this library as well as the necessary > devekopment link. The package should be named libfoo-udeb-dev and > declare a dependancy on libfoo-dev. The only files libfoo-udeb-dev > should provide is the ABI-changed library and the necessary > symlinks. 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). 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.) 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. Also, what happens with api incompatibilities? Is it entirely impossible to have different include libraries for the "real" lib debs and the udeb versions? Your guide has been very interesting reading. Thank you. Cheers T.
Attachment:
pgpodVv1vWKez.pgp
Description: PGP signature