[gentoo-amd64] Re: eselect problems

[Duncan]

"Mark Knecht" <markknecht@×××××.com> posted
5bdc1c8b0811241446s7b7b01e7qba78f4e6de060a38@××××××××××.com, 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 eva@gentoo, 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