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

Re: [proposal] udeb shlibdeps files

On Mon, 20 Jun 2005, Joey Hess wrote:

> d-i currently suffers from a mess involving the library dependencies of
> udebs. Most library udebs have different names than their corresponding
> deb, for example, libc6-udeb, but since the udebs that should depend on
> them are built on regular Debian systems, their dependencies are either
> calculated with dpkg-shlibdeps, and thus are wrong, or are hardcoded,
> and thus break, or are noneixistant.
> This problem makes d-i less robust at runtime since some needed
> libraries are only pulled in by luck. It makes d-i builds more fragile
> since the build system requires udeb dependencies to be satisfied, and
> so we have to build-depend on a bunch of libraries we do not really use
> for the build, and track changes to them. It makes the build hard to
> understand as well, since some other libraries enter the d-i images due
> to library reduction rather than as udebs, and it's hard to tell which
> libraries are intended to work which way.
> I propose that we fix this by making dpkg-shlibdeps generate correct
> dependencies on library udebs when building udebs. This will mean making
> it change its behavior when it is building a udeb, but rather than
> hardcode the concept of a udeb at such a low level, I think we can make
> it generic and possibly even useful for something else. So let's add a
> new switch to dpkg-shlibdeps, -t (for type), which takes a string parameter
> such as "udeb". The default type would be "deb".
> Then extend the shlibs file format, so some lines start with a marker
> indicating they only apply to packages of a given type. For example:
> libiw 28 libiw28 (>= 27+28pre8)
> udeb: libiw 28 libiw28-udeb (>= 27+28pre8)
> If no matching line of the right type are found in a shlibs file, it will
> fall back to the untyped lines.
> I think that with this small change to dpkg-shlibdeps, we can get the
> dependencies striaghtened out, and probably fully automate it all in
> debhelper. I would hate to try to implement something similar without
> changing dpkg-shlibdeps, so I hope that this meets your approval.

I don't see any problems with it.  But I haven't thought it thru deeply.

Reply to: