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. [EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
