[gentoo-amd64] Re: eselect problems

[Duncan]

Beso <givemesugarr@×××××.com> posted
d257c3560811250316g6a10f8ccoee464fe64c272fa7@××××××××××.com, excerpted
below, on  Tue, 25 Nov 2008 12:16:56 +0100:

> 2008/11/25 Duncan <1i5t5.duncan@×××.net>:
>> "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).
>>
> 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.

I'm not saying it can't happen, but if it does, it's certainly a bug, 
either of the package (not testing the keyword correctly) or of portage 
(not setting it correctly), or possibly of the user (maybe a typo, ~adm64 
instead of ~amd64, say).

Here's what I know:

From my make.conf:
ACCEPT_KEYWORDS="~amd64"

emerge --info |grep ACCEPT
ACCEPT_KEYWORDS="amd64 ~amd64"

So portage is actively adding the amd64 stable keyword, based on the 
~amd64 in make.conf.  It has done so since at least whatever portage was 
around for 2004.1, which is when I started with Gentoo/~amd64.  (As I 
switched from Mandrake Cooker for AMD64, I never even seriously 
considered stable Gentoo/amd64, and have run ~amd64 from day one.)  As I 
said, if it didn't work that way for some package, there was a bug 
somewhere!

Also note the wording in the handbook and the Code Listing 1.1 found here 
(link should be a single line, in case I forget to come back and unwrap 
this before sending or if it wraps on your end):

http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?
part=3&chap=3#doc_chap1

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

That sentence is rather difficult to parse, here.  I think it's probably 
because English isn't your native language, right?  See if the following 
accurately conveys your intention or if am I still confused?

"I [have] found out that [it] is better to have a short package.mask 
instead of a long package.unmask.  It's more efficient control of the 
stuff on your PC."

If that's your intent, I agree.  I prefer the shorter file version here 
myself.  It's just simpler to manage.

However you're not directly addressing what I was.  Note that I was 
talking about package.keywords as opposed to package.mask, not 
package.unmask, which I didn't mention at all.

I was suggesting that if one has ~arch by default and finds an individual 
package where one wishes to revert to to stable arch, it may be better to 
list the broken ~arch version in package.mask, thus reverting to the 
working arch/stable version, instead of using package.keywords to revert 
to stable.  For one thing, masking an individual version only affects 
that version, not newer versions, and in the next round, it's quite 
possible the ~arch version will be perfectly fine.  If one has created 
the entry in package.keywords, one will still be stuck with it for the 
next version, while if the individual broken version is listed in 
package.mask, the next ~arch release will show up as unmasked again, 
giving one a chance to evaluate whether the problem is fixed or not.  
Hopefully it is.

In practice I don't end up using package.mask very much.  Most of the 
time, if a package doesn't work, I check bugs and if necessary file one, 
but often someone already has a bug filed and there's already a patch 
available for me to apply.  I'll normally do that instead of masking the 
package.  And occasionally I'll leave an update unmerged for a couple 
days if it's broken, hoping either a further update is release or a patch 
appears on the bug (which I've CCed to if I didn't file it myself) that I 
can apply (in my local overlay or whatever) and then merge the package.  

If I put something in package.mask here, it's because it truly is broken 
on my config, perhaps because I often run hard-masked new gcc or 
baselayout/openrc versions or the like, before they even hit ~arch, or 
maybe because I tend to customize my system more than most and the 
package simply was never tested (even upstream) on a system that looked 
like mine before.  In any case, I check for a filed bug and file one 
myself if necessary.  Since that type of bug tends to take somewhat 
longer to fix than the trivial ones, if the package won't compile at all 
or has broken functionality I truly depend on, I'll package.mask that 
version and fall back to an earlier version until the bug is fixed, or in 
some cases I decide whatever customization I had that was breaking things 
isn't worth the trouble and I change it to something that works.

So I usually have a very small package.mask.  Right now there's only one 
entry in it, a permanent one, app-emacs/emerge, because one time I 
accidently double-typed "emerge emerge" and got /very/ confused when 
there actually /was/ a package called "emerge" and it tried to emerge it! 
=:^)  So I keep that entry there to give me a warning I can understand 
(instead of a long list of new packages I didn't expect), if I ever make 
that mistake again.

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

Well, keep in mind what you're replying to was written by a guy (myself) 
who doesn't have much personal use for stable.  Some people do, and I 
probably would too if I were running a production server on it.  But... 
Gentoo really does /not/ have an "Enterprise class" stable branch.  Every 
year or so the discussion comes up again on the dev list, and we've had 
devs try to start such a project, and devs leave when it didn't work the 
way they wanted it to.  The problem is that supporting such an ultra-
stable branch, backporting fixes to old versions instead of forcing 
upgrades, etc, requires enormous development and testing resources that 
Gentoo simply doesn't have, and as it's currently structured, IMO will 
never have because it's in conflict with the whole idea behind Gentoo, 
rolling updates and all.

Honestly, while I'll straight up admit I'm biased, I don't really see the 
purpose behind a Gentoo (as opposed to say Red Hat) stable in any case.  
The idea of a compile-your-own, seriously customizable (USE flags, 
CFLAGS), rolling update distribution, fits very well the user that loves 
that sort of customization and control, and sees keeping up to date with 
the latest as a good thing.  This is where Gentoo works best.

But it doesn't fit with the user who needs long term support, who would 
rather keep a known working version and only change the bare minimum to 
get security fixes and the like, who often needs a one-size-fits-all less 
customized install (a known and predictable set of CFLAGS, a known set of 
dependencies that always apply to a given package, etc) so it's efficient 
for third party and proprietaryware (Oracle, for example) folks to 
support them, etc.  That's the domain of the Enterprise distribution, and 
Gentoo's whole structure just doesn't fit.  Now, it certainly WOULD be 
possible for a third party to create a Gentoo BASED Enterprise 
distribution, and that would be great!  However, I'd argue that Gentoo 
itself can't do this, because it's antithetical to the very assumptions 
on which Gentoo is based, and were Gentoo to head that direction, it 
would by definition, lose those qualities for which it is known and which 
attracted many of us to it in the first place.

So as I said, every year or two there's a big discussion on -dev about 
trying to force Gentoo into the Enterprise mold, and unfortunately, every 
year or two when it does, some devs tend to get disillusioned and leave, 
because the rest of the devs resist casting Gentoo in concrete like that, 
and as a result, it'll never be the big money big business distribution 
these disillusioned devs seem to think they want.  But if they wanted 
that, my question is why they're working on Gentoo in the first place, 
when there's far better matches for that ideal.  Let Gentoo do what 
Gentoo does best, and let Red Hat do what Red Hat does best.

While we're at it, the same applies to the usual KDE/GNOME/XFCE/etc wars, 
and the VIM/EMACS wars, and ... and ...  I've come to realize that the 
approaches are just different, neither one "better", altho certainly 
individuals will find one or the other "better" for their individual 
needs.  But GNOME folks complain about the confusing array of 
configuration options available on KDE, and KDE folks complain about the 
crippling lack of configuration options and the "There can be only one 
best way and we know it" philosophy GNOME seems to have at times, and 
what few realize is that it's NOT a wasted duplication of effort, and 
that the GNOME folks wouldn't WANT the KDE folks there breaking their 
precious ONE BEST WAY ideas, and conversely, the KDE folks wouldn't WANT 
the GNOME folks trying to take away all those nice config options we 
like, so it really IS best they keep to their own projects, cooperating 
where they can of course, but still separate projects.  And a parallel 
idea applies to VIM/EMACS, etc.

Let each project do what it does best, and attract the devs and users 
that fit best, and let the alternatives continue to exist and flourish as 
well, so everyone finds a home that works for them, and nobody ends up 
breaking the already working just fine solutions others have developed 
for their own needs/wants niche.

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