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

[Beso]

2008/1/30, Duncan <1i5t5.duncan@×××.net>:
>
> 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.


for me it has worked as a charm and as i've said: the ebuilds that are
broken by it usually have ldflags removed so there's no need to worry
anymore for it. i found it something awesome after the libexpat-2 update.
without it i would have to emerge abour 300 packages (kde stuff, gcc,
mime-shared, firefox ecc) but with it i only needed something like 10-15
packages of which 7 were updates and 2 or 3 had use flags changed. the doc
about that flag is about 2 and a half years old and wasn't updated since
then. i bet that every single dev would advise to us the flag if you happen
to do have some packages that need to recompile broken stuff (x264-svn,
ffmpeg and xine-lib would push some package recompile).
i'd also advise to use the the --buildpkg feature for some high compiling
time packages like kdebase, gcc, openoffice or mplayer. since these packages
are likely to be the same for quite some time and they might be pushed into
recompilation by some other updates having them packaged on disk (they'd
require disk space when packaged) would mean to skip all the compilation
part and jump directly to the install one (of course if they would need to
be recompiled portage would do it).

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.


well, i'm more pleased by live ebuilds. i personally use a good ammount of
live packages, especially multimedia, xorg and some network stuff like
networkmanager and knm.

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>


usually that's the point of hard masking. when a package doesn't work then
it goes hardmasked.

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.


i still think that having the base system on the unstable arch isn't a very
good idea. i've used the same stuff for quite some time, but i found out
that it isn't a very good stuff. or at least 6 months ago wasn't a good
idea.

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


-- 
dott. ing. beso