Volker Armin Hemmann <volker.armin.hemmann@...> posted
200801300220.21430.volker.armin.hemmann@..., excerpted below,
on Wed, 30 Jan 2008 02:20:21 +0100:
>> also adding --as-needed as LDFLAGS should help you save some time in
>> recompiling stuff....
> yeah - no. Don't do it. It breaks stuff.
I think the breakage in most of the common stuff Gentoo devs anyway use
has been fixed by now. I know I've had surprisingly few problems (read,
ZERO problems) with it here. Surprising, as I expected at least a few,
but I've seen exactly ZERO.
That said, especially for those who just want things to work, without
having to futz with LDFLAGS and remerge something occasionally, I'd still
not recommend it. For those that enjoy the challenge of such things,
however, I'd say great! Go for it! And for those in the middle, well,
YMMV, as the saying goes. You probably lean one way or the other, so
take your pick.
As for amd64 vs. ~amd64, I'm 100% ~amd64 here, and have been from when I
started on Gentoo. In fact, I've read suggestions that Gentoo tends to
work better at ~arch than at stable, because ~ is where most developers
are, and it's not uncommon for certain incompatibilities with "old"
software, that is, the crufty stable stuff from months or years ago
that's common in stable, to be overlooked until some poor stable keyword
user files a bug. Yes, before stabilizing, the arch-devs and arch-
testers normally test a package against a full-stable system, but it's
simply not possible to test against every permutation of USE flags and
mix of merged apps. While it's certainly true that ~arch packages have
the same issue, at least there there's a decently active community of
testers actively reporting bugs and devs fixing them.
Were it conveniently possible, I'd say the most trouble-free scenario
would be to take only ~arch packages that had been ~arch for say a week,
minimum, after verifying that nobody had run into and filed any serious
bugs on them. That'd be after the initial test wave had done its
installation and testing, but before the cruft that often attaches to
stable had set in.
<brainstorming> What would be great would be a keyword system that would
allow just this, say ~ for initial testing, automatically upgraded to /
after the week UNLESS they've been marked ~~, with the extra ~
automatically added to ~ packages by a script if a bug has been filed,
blocking the automatic upgrade to /, and a bugzilla keyword that a dev
could add to put the package back on automated / track if they've decided
the bug isn't worth derailing the automated / upgrade over. Then people
could go full testing ~ mode if they wanted, / mode if they wanted almost
~ but wanted to be spared the pain of the most obvious bugs as found in
the initial testing wave, and full stable arch if they wanted crufty old
packages, say for a server only upgraded for security issues or the like,
Of course, YMMV, but ~ for the entire system, with appropriate site based
masking as Gentoo already makes possible with /etc/portage/package.mask
and the like, isn't as terrible or system breaking as some folks like to
make it out to be. By policy, ~ is only for stable track packages in the
first place. Obviously broken packages and those not considered stable
candidates normally never get even the ~ keyword, as they are kept in
development overlays or in the tree but without keywords or fully hard
masked, so ~ packages aren't the broken things a lot of people make them
out to be.
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
email@example.com mailing list