From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-amd64@lists.gentoo.org
Subject: [gentoo-amd64] Re: madwifi-ng not compile in amd64
Date: Wed, 30 Jan 2008 06:55:47 +0000 (UTC) [thread overview]
Message-ID: <pan.2008.01.30.06.55.46@cox.net> (raw)
In-Reply-To: 200801300220.21430.volker.armin.hemmann@tu-clausthal.de
Volker Armin Hemmann <volker.armin.hemmann@tu-clausthal.de> 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....
>
> 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@lists.gentoo.org mailing list
next prev parent reply other threads:[~2008-01-30 6:56 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-28 21:25 [gentoo-amd64] madwifi-ng not compile in amd64 agtdino
2008-01-28 21:54 ` Beso
2008-01-28 22:52 ` Volker Armin Hemmann
2008-01-29 7:51 ` Beso
2008-01-29 8:17 ` agtdino
2008-01-29 8:31 ` Steev Klimaszewski
2008-01-29 9:00 ` agtdino
2008-01-29 9:56 ` Beso
2008-01-29 10:52 ` agtdino
2008-01-29 11:22 ` Beso
2008-01-29 22:30 ` agtdino
2008-01-29 23:08 ` Beso
2008-01-30 1:20 ` Volker Armin Hemmann
2008-01-30 6:55 ` Duncan [this message]
2008-01-30 8:04 ` [gentoo-amd64] " Volker Armin Hemmann
2008-01-30 8:43 ` Beso
2008-01-30 16:59 ` Volker Armin Hemmann
2008-01-30 19:09 ` Beso
2008-01-30 19:47 ` Volker Armin Hemmann
2008-01-30 20:02 ` Beso
2008-01-30 8:32 ` Beso
2008-01-30 17:42 ` Duncan
2008-01-30 19:06 ` Beso
2008-01-31 10:14 ` Duncan
2008-02-03 13:42 ` [gentoo-amd64] new laptop ionut cucu
2008-02-03 13:55 ` Beso
2008-02-03 15:05 ` ionut cucu
2008-02-03 15:49 ` Beso
2008-02-04 7:39 ` ionut cucu
2008-02-04 8:11 ` [gentoo-amd64] " Duncan
2008-02-04 11:23 ` ionut cucu
2008-02-04 13:39 ` Duncan
2008-02-04 9:01 ` [gentoo-amd64] " Beso
2008-02-04 9:26 ` Beso
2008-02-04 13:48 ` ionut cucu
2008-02-04 14:21 ` Beso
2008-02-04 14:53 ` ionut cucu
2008-02-04 15:52 ` Beso
2008-02-06 11:50 ` ionut cucu
2008-02-06 13:44 ` Beso
2008-02-06 14:30 ` Brett Johnson
2008-02-06 15:45 ` Beso
2008-02-07 7:59 ` ionut cristian cucu
2008-02-07 8:48 ` Beso
2008-02-07 14:16 ` ionut cristian cucu
2008-02-04 11:51 ` ionut cucu
2008-01-30 8:18 ` [gentoo-amd64] madwifi-ng not compile in amd64 Beso
2008-01-31 22:19 ` agtdino
2008-02-01 8:26 ` Beso
2008-01-29 9:47 ` Beso
2008-01-29 10:30 ` agtdino
2008-01-28 23:21 ` [gentoo-amd64] Good Postfix / Mail Server how to Mateusz Mierzwinski
2008-01-28 23:24 ` Mark Haney
2008-01-28 23:45 ` Mateusz Mierzwinski
2008-01-29 2:15 ` Isaac Conway
2008-01-29 10:06 ` Peter Humphrey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=pan.2008.01.30.06.55.46@cox.net \
--to=1i5t5.duncan@cox.net \
--cc=gentoo-amd64@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox