heavy python-scour dependencies make fontconfig unbuildable

targeting to beta because a fontconfig update is needed for multiarch.

Do you have a preferred way to break the cycle? My preference would be to weaken the strict libfontconfig1 -> fontconfig-config dependency. The latter just contains configuration files, which are not related to the library ABI at all. In case fontconfig-config introduces a new option which only a newer library can handle the dependency needs to be bumped, but that's the case only very seldomly.

The other option would be to introduce manual changes to many dozen packages which currently use cdbs and ship SVG files, or to revert the image comparison which checks for correctness.

On Mon, Mar 14, 2011 at 06:20:46PM -0000, Martin Pitt wrote:
> Do you have a preferred way to break the cycle? My preference would be
> to weaken the strict libfontconfig1 -> fontconfig-config dependency. The
> latter just contains configuration files, which are not related to the
> library ABI at all. In case fontconfig-config introduces a new option
> which only a newer library can handle the dependency needs to be
> bumped, but that's the case only very seldomly.

I would not like us to change this fontconfig package dependency without
discussing with the Debian maintainer. I don't see a clear reason for it to
be a strict versioned dependency, but it's at least possible that we'll be
breaking a maintainer assumption about how the package dependencies work
that would bite us in a future merge.

> The other option would be to introduce manual changes to many dozen
> packages which currently use cdbs and ship SVG files, or to revert the
> image comparison which checks for correctness.

I think it's a departure from upstream handling of cdbs to have the package
now depend on such a huge library dependency tree. For other features, cdbs
provides integration but requires the consuming package to activate this
feature by adding the necessary build-dependency and rules include. It may
be late to fix this for natty, but I think it's important that we preserve
this feature of cdbs in the future, since cdbs is used by many packages that
are not part of the desktop stack.

(As an aside, I'm quite unhappy that cdbs continues to be used as a
catch-all for desktop-wide packaging changes. cdbs's architecture is buggy
by design, and the continuing drift from stock debhelper behavior, and from
upstream cdbs behavior, makes it all the harder to get rid of cdbs in favor
of dh.)

Do the affected packages have any common build-dependency, such as
gnome-pkg-tools, to which the python-scour dependency could be safely added
instead of adding it directly to cdbs? Is there any hope of implementing
dh_scour *without* pulling in this deep dependency tree?

Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Hello Steve,

Steve Langasek [2011-03-14 20:02 -0000]:
> I think it's a departure from upstream handling of cdbs to have the package
> now depend on such a huge library dependency tree. For other features, cdbs
> provides integration but requires the consuming package to activate this
> feature by adding the necessary build-dependency and rules include. It may
> be late to fix this for natty, but I think it's important that we preserve
> this feature of cdbs in the future, since cdbs is used by many packages that
> are not part of the desktop stack.

Agreed.

> (As an aside, I'm quite unhappy that cdbs continues to be used as a
> catch-all for desktop-wide packaging changes. cdbs's architecture is buggy
> by design, and the continuing drift from stock debhelper behavior, and from
> upstream cdbs behavior, makes it all the harder to get rid of cdbs in favor
> of dh.)

There's actually a plan to convert most of what we currently have in
cdbs rules to a dh_langpacks and dh_gnome, and put the latter in
gnome-pkg-tools, and make this a common build dep for GNOME packages.
This still needs coordination with Debian, but now that wheezy is open
it's a good time to do it.

> Do the affected packages have any common build-dependency, such as
> gnome-pkg-tools, to which the python-scour dependency could be
> safely added instead of adding it directly to cdbs?

Not right now, but gnome-pkg-tools would be the obvious candidate.

> Is there any hope of implementing dh_scour *without* pulling in this
> deep dependency tree?

I'm afraid not, the mangling of SVGs requires all these bits. However,
if it's only being pulled in through gnome-pkg-tools, it should be a
lot less intrusive than by cdbs itself.

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

This issue also applies to atk1.0 due to libatk1.0-0 -> libatk1.0-data, which unfortunately I discovered only after uploading atk1.0 and it failing to build on powerpc because i386 got published before powerpc started building it.

So fixing fontconfig is insufficient; if we can't fix this dep for cdbs, we at least need to fix atk1.0 and fontconfig, and probably some others.

Martin, what do you think is the right approach for cdbs for this cycle? I'll probably need to at least do a temporary upload of cdbs to drop the python-scour dep, in order to re-bootstrap atk1.0 for powerpc; should we at the same time start moving this over to gnome-pkg-tools? (unfortunately that doesn't help atk1.0, which also build-depends on gnome-pkg-tools!)

I'd like to note that this causes pain for people trying to bootstrap new architectures. Some circularity in build-dependencies is inevitable, and in some cases there is a good excuse; but the less of it the better.

This is now breaking builds for quite a lot of packages on powerpc, so I'm uploading cdbs to drop the dependency. If this functionality is needed as a space-saving mechanism, I think we need to add it elsewhere.

This bug was fixed in the package cdbs - 0.4.90ubuntu10

---------------
cdbs (0.4.90ubuntu10) natty; urgency=low

  * Drop dependency on python-scour so that we can build libraries in the
    GNOME stack again; workaround for LP: #734471.
 -- Steve Langasek <email address hidden> Sat, 19 Mar 2011 11:47:59 -0700

I'd rather drop the python-rsvg dependency from python-scour again then (this was added only recently).

This bug was fixed in the package scour - 0.25+bzr207-2

---------------
scour (0.25+bzr207-2) unstable; urgency=low

  * debian/control: Drop python-rsvg and python-cairo from Depends to
    Suggests, it's a too heavy build dependency, causing dependency loops.
    Point out rationale for the Suggests in the package description.
    (LP: #734471)
  * debian/cmpsvg: If rsvg or cairo modules aren't available, exit
    successfully with an error message.
 -- Martin Pitt <email address hidden> Sun, 20 Mar 2011 12:23:34 +0100

This bug was fixed in the package cdbs - 0.4.90ubuntu13

---------------
cdbs (0.4.90ubuntu13) natty; urgency=low

  * Put back python-scour and automatic SVG optimizations, now that
    python-scour has only lightweight dependencies any more. (LP: #734471)
 -- Martin Pitt <email address hidden> Sun, 20 Mar 2011 12:34:00 +0100