[gentoo-amd64] Re: eselect problems

[Duncan <1i5t5.duncan@cox.net>]

Beso <givemesugarr@gmail.com> posted
d257c3560811251519w7f8a0734jc27c23e2bf06404e@mail.gmail.com, excerpted
below, on  Tue, 25 Nov 2008 23:19:40 +0000:

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

Yeah, that could do it.  Not a problem... except that it wasn't until I 
actually started trying to deconstruct it as part of my reply that I 
actually made sense out of it.  Before that, I thought it internally 
conflicted with itself and figured I knew where you were trying to go 
with it, but wasn't quite sure.  Even afterward I wasn't sure I had it 
right, thus bringing it up to ensure I did.

... And while I don't understand more than a few words in any language 
other than English, I'm /usually/ pretty good at groking strange word 
ordering and etc, because I've been exposed to quite a variety of 
multiple cultures of /some/ sort or another (plus now archaic English) 
most of my life.  So I'm unaccustomed to not being able to make sense out 
of things, even if the word order is /not/ customary English.  But this 
one I really did get wrong at first.  It was a stumper!

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

Yes.  I've only had that happen a relatively few times, because I only 
use a relatively few overlays.  And when it did happen here, it just 
seemed to work the way I needed it to anyway, so I didn't trouble myself 
with it.  But certainly, once someone's running more than a small handful 
of overlays, it can get "interesting".

> this is one of the reasons that i've switched to paludis

That's one thing the paludis devs have gotten right.  It was designed 
pretty much from the beginning to handle multiple overlays and make 
configuring which one gets used for which packages relatively easy.

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

I used to do a lot of personal overlay stuff.  Now, I use Ed Catmur's 
portage-patches scripts, which hook into portage and allow one to apply 
one's own set of patches to a specified package.  It works for patching 
with an /etc/portage/patches tree much like the /etc/portage/env/ tree 
that the last few versions of portage have worked with for setting stuff 
like CFLAGS in a package-specific way.  (I only recently realized Ed 
Catmur is the author of udept, which I had merged previously, so he /
should/ be relatively familiar with portage tricks.)

Since I installed those scripts and now use package.keywords to set ~x86 
or whatever for some packages instead of putting them in the overlay and 
adding ~amd64, my personal overlay has remained almost empty.  I had a 
"live" pan ebuild, but eva@gentoo encouraged me to forward it when I 
mentioned it in a bug and it's now in the tree.  I have a copy of the 
amarok-1.4.9999 live ebuild that I needed to modify to install slotted 
and not conflict with the amarok-2/kde4 version, but that's about it.  If 
the patch is to the sources, I use portage-patches and use the existing 
ebuild without changes.  Only if the ebuild itself (or eclass, but that 
hasn't happened in awhile) needs patching, and it can't be handled by say 
setting EXTRA_ECONF in the /etc/portage/env tree either, does it end up 
in my overlay.  And that doesn't happen so often.  Usually it's a sources 
patch, and that can go in the /etc/portage/patches tree, thanks to Ed's 
portage-patches.

> 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

Hmm... I've been using --as-needed (in LDFLAGS but not forced in spec 
files) for awhile myself, but haven't seen my bugs ignored with it.  
Maybe it's the type of bugs I file, or the type of packages I end up 
finding bugs in and the devs that maintain them, or the fact that if
I think my custom LDFLAGS (or CFLAGS or still masked gcc version or ...) 
are causing problems, I set them to accepted Gentoo defaults for that 
package using a file in the /etc/portage/env tree, and specifically 
mention in my bug whether that changed the result or not.

One thing's for sure, I've certainly developed a much thicker skin over 
the years, since one of my originally filed bugs got marked INVALID for 
some stupid reason.  I don't just tuck my tail between my legs and go 
home like I used to, tho I've not had occasion to get into a real bug-
status war since that changed.  But my bugs don't generally seem to be 
ignored, either. Some don't get action for awhile, but it's not ignoring, 
it's the "real life" of the assigned dev, and the fact that some of my 
bugs are rather esoteric, so not /that/ system life threatening to 
anything.

But Flameeyes' campaigning on the --as-needed thing is certainly needed.  
I'm very glad he's doing it, as it's something few would have the skills 
to tackle, but at the same time, something he can let his new machine do 
much of the work on, so maybe he doesn't overwork himself so much.

Gentoo's lucky to have someone that talented around, and he doesn't have 
the enormous ego problems a lot of the similarly talented devs seem to 
have.  Unfortunately, like my dad and sister, he seems to be a 
workaholic.  They do great and wonderful things, certainly, but they they 
burn the candle at both ends doing it, and their health suffers as a 
result.  Having that problem in my own family, I recognize it in 
Flameeyes as well, and his frequent hospital trips at such a relatively 
young age concern me.  He's an asset not only to Gentoo, but to the FLOSS 
community in general, and I fear we're going to lose him if he can't 
learn to pace himself.  Fortunately, he seems to have realized that 
himself, now, and has cut back substantially from what he /was/ trying to 
do.

> O_O i didn't know that there was a package named emerge...

I didn't either... until then.  But I learned! =:^)

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

Maybe the next time someone brings up the Enterprise Gentoo idea on the 
dev list, I should counter with the dropping stable idea...  AFAIK the 
last time it came up was early this year, so it should be time for it to 
come up again sometime between this spring and next fall...

But they've already dropped stable keyworks on IIRC mips (but don't quote 
me on that, it may have been a different arch, and I'm too lazy to go 
check my devlist archives ATM), because it just wasn't happening, and 
maintainers were getting seriously annoyed due to having to keep outdated 
and broken packages in the tree as the only stable on that arch.

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

Yes.  But the problem tends to be that these Enterprise users need 
support, and for that to be economical, there has to be a reasonably 
large size group on the same packages built with the same set of options 
and CFLAGS.

They can get their support and run their proprietary packages, but to do 
it, the tradeoff is that they gotta accept being a clone, 
one-size-fits-all.  The hard economics of the situation are that as soon 
as you optimize for the hardware you're actually running, and build for 
the dependencies you actually need, you're in a niche that's small enough 
it's simply not economical to support you... at the level of commercial 
support that RHEL's customers demand anyway, or they'd be elsewhere.

Practically speaking, you and I know that in many, perhaps most cases, 
the benefit of such "support" is highly questionable anyway, because 
practically speaking, posting to the relevant list/newsgroup/forum gets 
an answer way faster than paid support is likely to.  And in the cases 
where it doesn't, paid support may fail as well.  And... being open 
source, for the few cases where that paid support does actually mean a 
benefit, it's quite possible a single-shot consultant or developer job 
could be funded to address that specific issue, customized solution, for 
roughly the same money but in less time than than the paid support.

But regardless, that doesn't provide someone else to point the finger at 
and save someone's a**, and... practically speaking, RHEL DOES pay a lot 
of paychecks for full-time FLOSS developers, that would at best be part 
time if it weren't for /someone/ deciding they needed that sort of 
support enough to pay the big bucks for it.

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

xorg is an interesting problem, not in the least because it has a very 
clear yet politically unpalatable solution, simply ignore users who chose 
hardware vendors whose only real competitive features are only enabled by 
proprietaryware drivers.  nVidia, and to a lessor extent ATI but that 
one's being solved as we speak, are, simply put, holding xorg development 
hostage to the rate at which they develop their proprietary drivers to 
match.  The logical thing to do would be to let xorg development and 
those user who have hardware with freedomware drivers continue their 
progress apace, and let the nVidia users be stuck on the two-years-
outdated or whatever proprietary development model they've chosen to 
support with their buying dollars.

Actually, if you look at it, that's gotta be one of the reasons Intel is 
pushing xorg development so hard.  It has a competitive advantage in that 
it's hardware, while not as full featured hardware-wise, has native 
driver support for the latest whiz-bang xorg features right off the 
blocks, leaving the proprietaryware folks sucking dust, and it's not 
above trying to exploit it.  AMD, who needs the Linux users far more than 
Intel does, was facing the very real prospect of being practically locked 
out of the Linux market due to Intel's Linux cooperation, and had no 
choice but to respond, first by buying a graphics maker so it wasn't 
locked out due to the proprietaryware actions of third parties, and then 
by opening up ATI's graphics to the same extent, or actually even 
further, pushing Intel.

But the gamers and their preferred nVidia proprietaryware are continuing 
to hold things back, at least as far as stable support, and not just for 
Gentoo.  All of the big distributions are facing the problem, as are 
Dell, Acer, Asus, and other OEMs now shipping Linux kit in some volume.  
No major distro can afford to cut off the nVidia user market share, so 
none of them can afford to ship a new xorg no matter how far behind their 
current version is, until nVidia deigns to support a newer xorg with 
their proprietary driver.  And $deity have pity on the poor distrib that 
has the luck of having nVidia release a driver just after they've frozen 
the repository to all bug bug fixes in preparation for a new release, 
because now they'll be shipping with an outdated nVidia driver AND xorg, 
and can't really upgrade either one except as options, without delaying 
release another month or two to test the new xorg with everything.  And 
if the major distros can't ship it, then the OEMs basing their own 
distribs on them can't ship it, even if they're using Intel hardware that 
could really benefit from the newer xorg.

Fortunately with the AMD purchase of ATI and its subsequent switch back 
away from the dark side, 2009 seems likely to resolve this.  The 
distributions and hardware OEMs both are getting increasingly impatient 
with nVidia, and with Intel support right there and AMD/ATI/Radeon 
support coming on fast, 2009 looks likely to be the year nVidia either 
reverses itself as well, or regardless, starts losing its ability to hold 
things back.

Bringing that all back around to our discussion at hand, for other 
distributions, that'll probably mean shipping a more modern xorg, with an 
optional stale xorg just to support nVidia users, and a * on their 
feature list with an "nVidia users" small-print disclaimer.  KDE's not a 
distribution, but it has already taken that tact by choosing not to 
support nVidia proprietary driver users at full feature strength some of 
the time.

Gentoo...  will probably either end up taking a similar position with 
stable, telling nVidia users to mask the newest stable until nVidia gets 
off their a**, or will continue to let stable xorg molder, updating it 
only when nVidia deigns to allow it by updating their proprietaryware, 
meanwhile forcing more and more users who want decently current features 
to either highly package.keyworded systems, or to fully ~arch systems.

Hopefully either nVidia or their proprietaryware driver users get a clue, 
but I'm not holding my breath...

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

KDE... has been a problem for Gentoo of late.  Well, KDE4 has been a 
problem for everyone, not just Gentoo, but Gentoo had problems before 
that, as you mentioned, from 3.5.x.

The real problem for Gentoo has been the size of KDE... and the devs on 
the project.  Losing developers, and before their loss, loss of 
cooperation with the rest of Gentoo, due to an inability to work well 
with others... hurts any project.  There are certainly two sides to the 
story and I'm not close enough to it nor do I have any desire to pick 
sides, so I won't, but the fact is, whoever was to blame or whether it 
was just the way things had to be, that loss /hurt/.  We're lucky a bunch 
of users got involved in the overlay work, or Gentoo basically wouldn't 
/have/ a modern KDE, either 3.5 or 4.x series, at this point.

Hopefully that's all behind us and KDE can become a thriving healthy 
project once again.  As I said, I'm a bit far from the action, but that 
influx of new blood, as well as some developers from other areas putting 
on another hat, has seemed to help, and the major teething problems with 
the switch to the 4.x series seem to be over, so I'm optimistic.

Otherwise, much as I hate to since Gentoo otherwise seems about the ideal 
fit for me personally, I may end up having to ultimately switch to 
something else (assuming KDE4.2 finally gets the kde4 act together 
upstream, as they've been promising, or maybe kde will be what I end up 
dropping), or perhaps more likely, simply switch to kde upstream directly 
for KDE stuff.

But none of the other really big projects seem quite as bad as Gentoo/kde 
and Gentoo/xorg.  In particular, toolchain seems to still be quite 
functional, and the PM side is strong enough it's supporting three 
thriving PM!  What about GNOME and XFCE?  I've not /read/ of anything so 
majorly wrong with those projects and from outside, they've seemed much 
smoother, but unless GNOME reverses course with gnome3, it's not for me, 
and xfce... well, I guess I've never seriously looked at it, but I've 
always thought of it as not as full featured as I like... and my hardware 
certainly isn't the issue it seems to be for a lot of xfce users.

For everything else, at least for desktop use, it doesn't seem to me that 
stable lagging a bit should be a serious problem.  If someone needs codec 
support only in a new media-* package, unlike xorg or toolchain or the 
desktop environment, they can package.keyword it without threatening the 
stability of either the computer itself or at least their entire desktop.

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

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

Exactly.  Especially when "progress" as defined by some is "regression" 
as defined by others.  When that's the case, as it is for example with 
the proliferation of user accessible controls on KDE as compared to 
forced conformance to the "One True Way" (tm) on GNOME, it's /better/ to 
have separate projects, and far from hurting each other, they keep the 
devs who might otherwise cause problems and needless infighting on the 
other alternative, working on their preferred alternative instead.  Where 
it's possible and convenient, they can always cooperate, and 
freedesktop.org has been very good at bringing that with its various 
hosted projects, while letting the desktop projects otherwise pull in 
their opposing directions without hurting anyone, and in particular, 
without hurting the interests of the wider FLOSS community.  Why so few 
see it and calls for "One True Desktop" (tm) are so common, I don't know, 
except that those folks must still be thinking the "One True MS Way" (tm).

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

Some people like the security and comfort "Big Brother" (tm) provides...

I could go off on a US political tangent here, or for that matter, on a 
big bad MS tangent, but I won't...  The big bad nVidia bit above is 
enough for this post. =:^)

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

That's what's nice about choice and the FLOSS community way of developing 
a bunch of competing solutions in parallel.  That cross-pollination is 
not just allowed, but actively encouraged! =:^) 

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

Of course, the Boycott-Novell folks have a very different view of things 
there.  But fortunately for me, I've been far enough away from that I've 
had no need to develop an informed opinion on it.  I very seldom have to 
deal with Office formatted docs of any kind (save for the usual .pps cute/
funny mail stuff making the rounds, and I just ignore that), I don't use 
Gnome for other reasons and haven't had to deal with mono, and Gentoo's 
sufficient for me so I've little interest in Novell/SuSE as a 
distribution.  So I've sufficiently few dealings with them or their 
controversial products that a boycott really isn't something that would 
affect either them or me.  The work of Greg KH (Novell employee, AFAIK) 
on the kernel is about as close as it gets, here, and evidently his 
integrity is sufficient I've seen nothing calling that into question.

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