Volker Armin Hemmann <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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, somewhere. </brainstorming> 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 protected] mailing list
