[Build-common-hackers] Bug#448141: Proposed list of issues in ffmpeg/experimental
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,
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
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?
More information about the Build-common-hackers