[gentoo-amd64] Re: madwifi-ng not compile in amd64

[Duncan]

Volker Armin Hemmann <volker.armin.hemmann@××××××××××××.de> posted
200801300220.21430.volker.armin.hemmann@××××××××××××.de, 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

-- 
gentoo-amd64@l.g.o mailing list