"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). > Also, when you say '~arch' on this list do you really mean ~amd64, or is > there a real ~arch that I've not learned about? ~arch (arch being short for machine-architecture, with the stable equivalent then being just arch or simply stable) is simply the generic term for what on Debian would be (AFAIK) testing, for any machine type, amd64/x86/ppc/ppc64/mips/superh(sh)/whatever, altho some of the lower use ones are classed as experimental and only get ~arch. They don't get full stable as there's simply not enough devs and ATs on those archs to keep up with stable testing. > 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. Another bonus of ~arch is that you very seldom ever have a security upgrade to worry about (I've seen one in >4 years), because most of the time you're well past the afflicted versions in any case. At least that's the case if you also do --deep by default when you upgrade, as I do. The parallel down-side, however, is that there's quite a bit more package churn on ~arch -- a package may go thru several -r versions and occasionally even several upstream releases for ~arch, before one is actually demonstrated to be stable enough to be keyworded straight arch. The packages I /do/ have listed in package.keywords are usually there so I can keyword them something else, perhaps ** if I'm testing a package that has no arch keywords at all yet (KEYWORDS="", the empty set). or occasionally x86 if I'm testing something that's keyworded for it but has no amd64 keyword at all, ~ or not. In theory it could be something else too, but it's relatively unlikely to be needed as long as x86 and amd64 are the majority archs. > 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. Of course, there's also the occasional pure mistake, plain and simple, where some dev goofed and something got marked stable that shouldn't have been. But as I was explaining earlier, other than the occasional simply broken config that's normally caught before a package gets anywhere near stable, I believe someone running ~arch and regularly updating --deep is probably less likely to run into issues than somebody running who knows /how/ old and stale deep dependencies that simply haven't been upgraded in ages, because nothing required it, the user is on stable so they're behind upstream's development edge in any case, and the user normally doesn't use --deep when he does his upgrades so the dependencies tend to stay at the absolute minimum version necessary to work, which can as I said be years behind what the upstream provider of the package is working on, and broken in all sorts of ways against current versions of gcc and glibc and the various dependency libraries. Here's a bit of the upstream perspective. I'm not a dev per se but I'm relatively closely involved with the pan (nntp/newsgroup client) upstream, being AFAIK the oldest and most active regular on the pan user and developer lists. Most users on the lists will be using the latest version or close to it, and when a new version of gcc or glib or gtk comes out, we'll be working on patches to get pan working with the latest. Someone with better development skills than me usually gets a working patch relatively quickly, and we all submit it to our various distributions (I submit to Gentoo, of course, and have a working relationship with [EMAIL PROTECTED], the Gentoo dev that usually handles pan) and the pan/gnome bugzilla itself, so Charles (the actual developer) can incorporate it in the next release when he gets around to doing one. Then six months or a year later, we get people coming in with the same problems we dealt with back then and have by now forgotten the details of, asking how to get two-year-old pan versions to compile. That's not even counting the ones still using the old and no longer updated pan 0.14.x C language version, when upstream pan has for /years/ now been an entirely recoded in C++ version, starting with 0.90 and now on 0.133. (To be fair, the new C++ version hasn't had an official "stable" release upstream yet, but it works better than the old crufty code ever did, the old code is now broken on anything like a modern compiler or against modern glib or gtk, and despite the lack of an official stable new-code version, the old-code is officially unsupported now, with no further development taking place.) So I know first hand from an upstream perspective what it's like trying to deal with years outdated "stable" versions. Then there's the fact that with 0.132 released Aug. 1, 2007, and an updated 0.133 released exactly a year later, Aug. 1, 2008, the unpatched 0.132 as STILL carried by Ubuntu even in their latest 2008.10 release, HAS A KNOWN SECURITY VULNERABILITY! This despite the fact that a patch was released in late May, and they've had a security bug open on it, just sitting there for nearly that long! (I personally filed the Gentoo bug in late May, the ~arch version was patched within two weeks, and an upgrade with the patch was stabilized and GLSA released by July, AFAIK.) Needless to say some of us pan upstream regulars are a bit irritated at Ubuntu right now, with who knows how many users not only from the 2008.4 release but now the 2008.10 release as well, left vulnerable to a publicly known security bug. 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. -- 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
