Le dimanche 04 septembre 2005 à 03:04 -0700, Steve Langasek a écrit : > 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.
Sure. However, when you try to rely on these options for a package, things are not that easy. -O3 doesn't really bring anything and you can drop it anytime, but -Wl,--as-needed is a feature. If a feature isn't guaranteed to work across versions, you can't start to rely on it, so it shouldn't even be here. > (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.) As most of GNOME 2.10 is ready to enter testing, and as I don't have the skills to fix binutils, I don't really have a choice, and will also upload a gnome-session without --as-needed, but this isn't a good long-term solution. Time spent re-uploading stuff and checking complex dependencies isn't spent fixing other bugs. > > 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. The fix for libtool is available, but requires relibtoolizing packages at each version, so it's even more work, and it's tedious work no one is willing to do. The GNOME team manages to handle so many packages only because we made simple packaging operations, like new upstream versions, a trivial operation. I'm not aware of any solution for pkg-config. It would probably need a large rework, e.g. separating --shared-libs and --static-libs. And even with both of them fixed, I'm afraid we'd still have issues with random libraries added to the linkage without the need for them, or badly written foo-config scripts. Except in some weird cases, --as-needed solves all these issues. It may not be the Right Thing(tm), but it makes good packages in the end. Regards, -- .''`. Josselin Mouette /\./\ : :' : [EMAIL PROTECTED] `. `' [EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
signature.asc
Description: This is a digitally signed message part
