From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1JK6re-0004qp-MI for garchives@archives.gentoo.org; Wed, 30 Jan 2008 06:56:06 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 03A20E05C3; Wed, 30 Jan 2008 06:56:05 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by pigeon.gentoo.org (Postfix) with ESMTP id B0436E05C3 for ; Wed, 30 Jan 2008 06:56:04 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JK6rW-0007QG-Uy for gentoo-amd64@lists.gentoo.org; Wed, 30 Jan 2008 06:55:58 +0000 Received: from ip68-231-12-179.ph.ph.cox.net ([68.231.12.179]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Jan 2008 06:55:58 +0000 Received: from 1i5t5.duncan by ip68-231-12-179.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Jan 2008 06:55:58 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: madwifi-ng not compile in amd64 Date: Wed, 30 Jan 2008 06:55:47 +0000 (UTC) Message-ID: References: <1201555535.24379.1.camel@gentoo> <1201645850.7098.8.camel@gentoo> <200801300220.21430.volker.armin.hemmann@tu-clausthal.de> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@lists.gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-12-179.ph.ph.cox.net User-Agent: Pan/0.132 (Waxed in Black) Sender: news Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 1cf3e39e-33ca-42b8-9e3d-b857c7848411 X-Archives-Hash: 9ccfd660aa8f5dcf63584293c939d090 Volker Armin Hemmann posted 200801300220.21430.volker.armin.hemmann@tu-clausthal.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.... >=20 > yeah - no. Don't do it. It breaks stuff. I think the breakage in most of the common stuff Gentoo devs anyway use=20 has been fixed by now. I know I've had surprisingly few problems (read,=20 ZERO problems) with it here. Surprising, as I expected at least a few,=20 but I've seen exactly ZERO. That said, especially for those who just want things to work, without=20 having to futz with LDFLAGS and remerge something occasionally, I'd still= =20 not recommend it. For those that enjoy the challenge of such things,=20 however, I'd say great! Go for it! And for those in the middle, well,=20 YMMV, as the saying goes. You probably lean one way or the other, so=20 take your pick. As for amd64 vs. ~amd64, I'm 100% ~amd64 here, and have been from when I=20 started on Gentoo. In fact, I've read suggestions that Gentoo tends to=20 work better at ~arch than at stable, because ~ is where most developers=20 are, and it's not uncommon for certain incompatibilities with "old"=20 software, that is, the crufty stable stuff from months or years ago=20 that's common in stable, to be overlooked until some poor stable keyword=20 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=20 simply not possible to test against every permutation of USE flags and=20 mix of merged apps. While it's certainly true that ~arch packages have=20 the same issue, at least there there's a decently active community of=20 testers actively reporting bugs and devs fixing them. Were it conveniently possible, I'd say the most trouble-free scenario=20 would be to take only ~arch packages that had been ~arch for say a week,=20 minimum, after verifying that nobody had run into and filed any serious=20 bugs on them. That'd be after the initial test wave had done its=20 installation and testing, but before the cruft that often attaches to=20 stable had set in. =20 What would be great would be a keyword system that would=20 allow just this, say ~ for initial testing, automatically upgraded to /=20 after the week UNLESS they've been marked ~~, with the extra ~=20 automatically added to ~ packages by a script if a bug has been filed,=20 blocking the automatic upgrade to /, and a bugzilla keyword that a dev=20 could add to put the package back on automated / track if they've decided= =20 the bug isn't worth derailing the automated / upgrade over. Then people=20 could go full testing ~ mode if they wanted, / mode if they wanted almost= =20 ~ but wanted to be spared the pain of the most obvious bugs as found in=20 the initial testing wave, and full stable arch if they wanted crufty old=20 packages, say for a server only upgraded for security issues or the like,= =20 somewhere. Of course, YMMV, but ~ for the entire system, with appropriate site based= =20 masking as Gentoo already makes possible with /etc/portage/package.mask=20 and the like, isn't as terrible or system breaking as some folks like to=20 make it out to be. By policy, ~ is only for stable track packages in the= =20 first place. Obviously broken packages and those not considered stable=20 candidates normally never get even the ~ keyword, as they are kept in=20 development overlays or in the tree but without keywords or fully hard=20 masked, so ~ packages aren't the broken things a lot of people make them=20 out to be. --=20 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 --=20 gentoo-amd64@lists.gentoo.org mailing list