2008/11/25 Duncan <[EMAIL PROTECTED]>: > "Mark Knecht" <[EMAIL PROTECTED]> posted > [EMAIL PROTECTED], excerpted > below, on Mon, 24 Nov 2008 14:46:35 -0800: > >>> Personally, I default to ~arch, and unmask hard-masked packages either >>> in- tree or from various overlays from time to time as well. >> >> Where do you do this? In /etc/make.conf? I've never run a machine like >> that but would be interested in at least seeing how many packages this >> machine would have to rebuild if I went there. > > Yes, I set ACCEPT_KEYWORDS=~amd64 (which automatically includes stable > amd64 as well, as shown by an emerge --info) in /etc/make.conf. You'd be > surprised at how far out of date stable arch is in some cases. Of course > in other cases, generally mature and real slow moving packages, the > latest version available has long been stable on most or all archs (see > below). > if i recall corectly in the past some packages that were under amd64 only needed also accept keywords amd64 near ~amd64. has this changed lately? usually the latest includes the former but sometimes when the packages are just amd64 and no ~amd64 ones i remember that i needed to add amd64 also in the keywords.
>> Generally I've always run stable and then never shied away from having a >> larger set of file in my package.keywords file to get what I think I >> want to run. > > With ~arch by default, you normally have very few packages listed in > package.keywords. There /may/ be a few individual packages that you > choose to stay with stable on, but at least here, I don't use > package.keywords for that but rather, package.mask, and mask whatever > individual version I'm having problems with, thereby forcing portage back > to a previous version, whether that's stable or an earlier ~arch version. > i found out that is better to have a less long package.mask instead of a long package.unmask. it's faster to controll the stuff in your pc. >> I don't think that running 'stable' anymore really means stable. package >> management has (IMO, really) gotten rather arbitrary over the last 2 >> years to the extent that I know of multiple people who have left the >> distro because stable packages are really broken. It's hard on some >> people with certain workload models (say a professional recording >> studio) to run stable, do updates, find new software is broken, and then >> have to downgrade. Lost time is lost money. I know of at least 4 that >> have moved onto other prepacked distros in the last year. Disappointing. > > I've heard that before, but as I run ~arch by default, I obviously have > no personal experience to go on. What I believe happens is that devs by > definition will be running ~arch on many of their boxes, and that while > they are supposed to and I'm sure do actually test on a stable box before > marking stable, the test sample size is by practical reality relatively > small, and sometimes, when the package hits the larger stable user base, > there /will/ be the occasional configuration that breaks, because there > was simply no case of it in the tested sample base. > if there's the lack of testing devs for going into stable i don't really know if it worths to continue keeping this distinction. maybe it would be better to have something like a hardened branch in which to go with only stable and secure stuff that gets updated rarely but that can be used as production system. more like the fedora red hat enterprise approach, where red hat is very stable and not updated very often if not for security reasons and fedora that gets the new stuff. > At least Gentoo stable isn't /that/ bad! We got our updates and the GLSA > out, and the old/vulnerable versions hard/security masked and then > removed. But perhaps you get the idea why I don't find stable a choice > particularly usable for me personally at least, now. Of course I'm > closer to pan upstream than anything else, but knowing what I know about > stale stable packages often lacking all the fixes (security and > otherwise) of the latest upstream version with pan, it has only made me > more of a confirmed ~arch user than I would have been otherwise. > well, glsa sometimes aren't marked right. i still have some glsa that get out from time to time that have already been fixed. an example is unace. -- dott. ing. beso
