[Build-common-hackers] Bug#448141: Proposed list of issues in ffmpeg/experimental

Loïc Minier lool at dooz.org
Mon Sep 22 10:06:32 UTC 2008

On Mon, Sep 22, 2008, Fabian Greffrath wrote:
> Which libraries do you mean by "leaf" libs?
> Is it better to order library packages in debian/control like libfoo0, 
> libfoo-dev, libbar0, libbar-dev or libfoo0, libbar0, libfoo-dev, 
> libbar-dev?

 leaf is respective to deps, e.g. if libfoo depends on libbar, you want
 to process libbar first.  Since libfoo-dev might depend on libbar as
 well, you want something like libfoo, libfoo-dev, libbar, libbar-dev,

> BTW, I consider it a bug in CDBS/debhelper/Debian-packaging-in-general 
> that packaging results depend on the order of package names in 
> debian/control, please see #448141 as an example.

 I don't; I think it's a design decision of CDBS that each package is
 considered separately.  The dh-make templates call dh_* commands with
 flags that act on groups of packages, CDBS always calls dh_* commands
 with -p<pkg>.

 While you have an "order or execution" constraint in dh-make's
 templates which isn't documented (if you move the dh_shlibdeps call
 before dh_makeshlibs, it breaks), you have an "order of package
 processing" constraint in cdbs' design.

 (BTW, this only works with recent dh_shlibdeps/dpkg-shlibdeps; it
 didn't before symbols support -- see below).

 We have package inter-dependencies in GNOME packages like the one you
 added since years:
    binary-gnome-mag :: binary-$(libgnome-magN)

 This is tricky, many people don't know about it, but it's not a "bug".

 In the past, it was more obvious than it is now because you had to call
 dh_shlibdeps with -L and -l:
DEB_SHLIBDEPS_LIBRARY_gnome-mag := $(libgnome-magN)
DEB_SHLIBDEPS_INCLUDE_gnome-mag += debian/$(libgnome-magN)/usr/lib/
 but this isn't the case anymore as dpkg-shlibdes got clever.  The
 dependency was pretty clear between dh_shlibdeps or package ordering
 when we had explicit -L / -l flags!

 Perhaps dpkg-shlibdeps should be /even more/ clever and detect when
 you're foolishly using shlibs from the system instead of the currently
 built package when the lib's source is the currenlty built source?  It
 can already fail when it doesn't find shlibs.
   Perhaps we should add lintian checks to help maintainers add explicit
 deps or a safe debian/control ordering?

Loïc Minier

More information about the Build-common-hackers mailing list