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

[Volker Armin Hemmann]

On Mittwoch, 30. Januar 2008, Duncan wrote:
> 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.

aren't bug reports with --as-needed closed as invalid per default?

>
> As for amd64 vs. ~amd64, I'm 100% ~amd64 here, and have been from when I
> started on Gentoo.

when I started with gentoo, there was no 'stable' or 'unstable'.

And IMHO that was a lot better. But some day some people tried to turn gentoo 
into a 'debian from source'. 

> 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.

from my experience, go stable or unstable. But don't mix. And a better name 
for stable would be 'stale'.

That said, a lot of problems who hit me as an unstable user hit my 'stable' 
friends too. So why use 'stable' at all?

>
>
> <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>

what would be great would be recognizing that 'stable' does not work.

>
> 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.

exactly.

~arch is not for broken packages, brocken or highly experimental stuff is in 
package.mask.


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