Re: [gentoo-amd64] Re: eselect problems

[Beso]

2008/11/25 Duncan <1i5t5.duncan@×××.net>:
> Beso <givemesugarr@×××××.com> posted
> d257c3560811250316g6a10f8ccoee464fe64c272fa7@××××××××××.com, excerpted
> below, on  Tue, 25 Nov 2008 12:16:56 +0100:
>
>>>> 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."
>
it has been written in a hurry at work, while speaking at the phone
with an italian
customer...
so i've spit out a rather difficult to understand sentence.

> 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.
>
same as before...

> 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.
>
this works for packages in gentoo. the problem is when the same package
is provided in other overlays. I tend to use quite a big number of overlays
and in that case the package mask is mandatory when you want to mask
a specific version and overlay. sometimes when the version is the same
this is proving difficult with portage. this is one of the reasons that i've
switched to paludis long ago when masking a specific package from an
external overlay wasn't really simple (if the version was the same of the
one present in portage).

> 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.
>
this also applies when i want to mask/unmask stuff from my personal testing
overlay (mainly patches against some build that fails).
also when using masked ebuilds, like the live ones, the use of package.unmask
and sometimes package.mask is quite useful.

> 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.
>
my problem is that my bugs are ignored due to --as-needed. now that diego
has started to massively test the --as-needed flag as default maybe would be
useful to go back reposting bugs that i might find. i'm now curently undergoing
a full system backup and automatizing it via rsync and cron and after that i'd
recompile whole world with forced --as-needed and --no-undefined and i
expect quite some issues with kde4, since i still haven't understood if xmlrpc-c
is really broken. so i need a backup of a fully working system before
undergoing
this recompile.

> 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.
>
O_O i didn't know that there was a package named emerge...

>> 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.
>
well, this also applies to the stable branch. then there are also the keyworded
packages. i know that when gentoo came out this distinction (as it is still now)
it has been a really good one, but still, nowadays when the unstable branch is
as stable as the stable branch, with a big lack of devs, maybe it's
better to think
of dropping one of the 2.

> 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.
>
it's simple in my opinion. rhel offers a big stability with a lot of
security features
and so on. but it has a downside: it's built on classic and not optimized flags
and the packages that are built are fully built, and not only with the
stuff you
really need. having a branch that has similar features, but it's optimized for
a specific machine and takes full potential from that machine would be a boost.
don't you think so?!

> 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.
>
then we're back to the point when the distinction between stable and unstable
is still a little useless nowadays. the release time between one
version and the
following is going to decrease as time goes. an example is xorg. just
think of how
many xorg-server versions have been released recently, and from what i've read
the project would be pushed farther form intel that wants a fully featured and
working environment for professional use. which has been the latest stable xorg
ebuild?! or for kde 3.5.7 and superior serie. the time in which it
went stable has
been very high. and the same reduction in time between releases is happening
for other projects as well. i really think that this stable/unstable
division should
really be revised, especially when there's a problem with the lack of
testing devs.

> 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.
>
well, i'm not into starting a flame war for this, but in my opinion is more
sensate doing something similar than continuing with the stable/unstable
distinction, that in the last period doesn't really apply anymore.

> 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.
>
well, it' s better to have a choice and a battle between them than having one
solution that doesn't progress, or that progresses in a bad way, as happens
on windoze for example.

> 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.
>
i do agree with this point, but sometime it's better to have some arguing about
new solutions and to try them out. you can always learn something new. as a
little example, i have a friend that is fully convinced that linux is
not capable of
doing what windoze svista would do. i just showed him kde4 with compiz enabled,
put on wow on codeweavers (thanks to the free giveaway offer from some
time ago)
and installed the native enemy territory and he remained stupified. he
didn't believe
that he could do the same things that he could do on windoze in a better way and
more intuively on linux. now he's still staying with his windoze but
he doesn't pretends
anymore that linux is bad and not working. the same could apply for gnome when
speaking of innovative features, or to kde when speaking about eye
candy or too much innovation
all together. everyone should sustain their ideas and show them to the
other part so
that the other one could learn something from it. and i think that
when this happens
everyone gets stronger than before. the same discussion might apply for
microsoft-novell agreement that is has bought a very high
compatibility with office
documents to openoffice 3, so that everyone might continue to use whatever he
likes without really worrying that the others could or couldn't understand them.

-- 
dott. ing. beso