Bug#319162: NMU patch

[Steve Langasek]

On Sat, Sep 03, 2005 at 11:42:25AM +0200, Josselin Mouette wrote:
> Le samedi 03 septembre 2005 à 00:31 -0700, Steve Langasek a écrit :
> > Yeah, right.  binutils is unmaintained; the issue couldn't possibly be
> > that you've made poor design decisions in your packages by making them
> > dependent on kludgy, non-default toolchain options that policy doesn't
> > require the toolchain to support at all...

> Policy? What does binutils working properly have to do with policy?
> Policy documents existing practice, and existing practice is to use this
> option. This is a regression in the toolchain for some architectures. No
> more, no less. If there aren't enough skilled people to fix the
> toolchain for some architectures, this isn't a good sign for the health
> of that port.

If you're going to blame build failures on the toolchain, then policy
(and release policy) is quite relevant.  There are in fact quite a few
toolchain options that *are* specified in policy: -O2, -O1, -O0, -g,
-Wl,-z,-defs, -Wall... and -shared is implied, of course... if a compile
fails when using one of these options, you have grounds for demanding
that the toolchain be fixed instead of trying to work around it in your
package. If you're using other, exotic toolchain options like -O3 or
-Wl,--as-needed, I believe the burden must lie primarily with the
package maintainer, not with the toolchain maintainer.

> Today, --as-needed can't be fixed, obviously because nobody skilled
> enough is willing to work on it. What are you going to do if "default"
> linker options are broken tomorrow?

Alternate explanation: the breakage in --as-needed wasn't noticed
upstream because it's a fringe option that isn't even clearly a good
idea, so it wasn't until Ubuntu and Debian packages started building
with binutils 2.16 that anyone noticed it was broken, so the breakage is
not a reflection on the viability of the porter teams for those archs.
(AIUI, there is actually activity upstream on getting a fix for this
bug; I just don't think the binutils maintainers should drop everything
else they work on to fix --as-needed, and I don't think you should wait
on binutils before fixing these build failures in your packages.)

> And after all, you're the release manager, so you'll be the one to deal
> with the horrible mess of gnome-games dependencies when all indirect
> dependencies are explicit. Great to see how you welcome design decisions
> taken to ease your work.

Yes, library dependencies are a major concern of mine, as I wrote at
<http://people.debian.org/~vorlon/dependency-hell/>.  But two design
kludges don't make a good solution, as they say (paraphrased); I believe
this is a problem we need to be fixing at the root, which is libtool and
pkg-config, instead of painting over it.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon at debian.org                                   http://www.debian.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20050904/acc7dbc7/attachment.pgp