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

Re: rfc: A guide for packaging library udebs



* 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



Reply to: