[gentoo-amd64] Re: kdelibs insanity

[Duncan]

"Arttu V." <arttuv69@×××××.com> posted
fecdbac60907301228s1ca607axbb6a6baec4350ee0@××××××××××.com, excerpted
below, on  Thu, 30 Jul 2009 22:28:17 +0300:

> I don't think there is a need to sync. qt-core, qt-gui,qt-sql, and
> qt-opengl just must all have either qt3support on or off, mixing them
> with different USE flag settings won't work.

Exactly.  Remember, it's basically a single package, upstream.  So it's 
best to treat all split packages from it as a single unit, same C(XX)
FLAGS/LDFLAGS, same USE flags, for the whole package.

Also note that it doesn't work well to have the different parts be 
different upstream versions (IOW, the -rX number doesn't have to match, 
because that's Gentoo-only, but the upstream version, everything before 
the -rX number, should match).  If one is upgraded, all the others should 
be as well, to keep them all in sync.  Doing otherwise WILL mean 
problems.  For those routinely doing --deep upgrades, that won't be a 
problem as they'll all become available together and the --upgrade --deep 
will ensure they're all upgraded together.  Those not using --deep, 
however, will have to ensure that the versions stay synced, tho AFAIK the 
packages now use blocking of other versions to help ensure that remains 
the case.

> Also, kde4-base.eclass
> seems to require qt3support on, so there isn't much choice about
> configuration here ... OP just hasn't gotten the whole mile, yet.

Also correct.

FWIW, I don't pay attention to whether something's listed as a global USE 
flag or local, I decide which I want as the system default, and put that 
in my make.conf USE flags.  The only entries I have in package.use are 
then those where I want something other than the system default, for some 
reason.  In this case, qt3support was a no-brainer for me since I knew 
kde was going to require it, so qt3support went in make.conf as turned on.

BTW, I also strongly prefer to decide how I want my USE flags set, and 
put that in make.conf and for changes for individual packages, 
packages.use, regardless of whether they're turned on or not.  Thus, 
there's a decent number of -flag entries in my USE flags.  That way, I 
don't have to worry about profile changes or the defaults on individual 
packages changing, since I have the policy set system-wide to what I 
want, regardless of what the package or profile defaults are.  That saved 
me a lot of trouble when I switched from the desktop to the no-multilib 
profile, for instance, and to a lessor extent, saves me trouble /
whenever/ I upgrade profiles (when I upgraded to 2008.0, for instance).

It also would have saved a lot of trouble for the OP here, since Alex 
pointed out that the reason this is coming up is that the qt package 
defaults changed.

> But you are right: OP should just enable qt3support in /etc/make.conf --
> or arduously list out at least the four qt-* packages with qt3support
> enabled under his choice of files/dirs under /etc/portage if he is a
> micromanagement-masochist.

=:^)  It should be obvious from the above which I'd choose, make.conf, 
tho as I said, I actually prefer to set -flags in there as well, which 
might be called micromanagement too.  package.use is only for packages 
that I want flags that don't fit my chosen system defaults.

For example, I don't run aRTs and have the flag turned off system-wide, 
but have it turned on in package.use for kdelibs:3.5, as I have arts-
plugins-xine installed to generate video thumbnails, and it needs the 
arts flag turned on in kdelibs.  (Rant: I don't know why I have to have 
aRTs installed to get video thumbnails, as I said, I don't actually use 
aRTs, but that's the way the package is setup.  <shrug>)

> About his pondering on whether Gentoo is right for him and about Gentoo
> having been more and more work to maintain recently -- I wholeheartedly
> agree. I just haven't found anything better, yet.

I don't agree.  Gentoo's about the same as it has been, even lower work 
if anything for me recently.  But then again, I believe I use better 
management techniques than many users do -- at least better for me.  And 
as what was working for others seems to be causing issues now, perhaps 
they'd be better for them, as well.  <shrug>

As I said, I prefer deciding what I want for USE flags and setting that 
globally, either hard on or hard off, and only change that for specific 
packages.  And I always do --upgrade --deep --newuse, preferably syncing 
and running upgrades at least twice a week, so nothing on my system gets 
too stale -- including all the deep dependencies.  I'm ALWAYS at the 
latest unmasked (to ~arch since that's what I use) version, which I think 
helps even if it does mean a bit faster churn on deep dependencies than 
I'd otherwise have.  And, upgrading twice a week means I normally don't 
have many packages to upgrade (big kde upgrades being a huge exception, 
since that's /always/ well over 100 individual packages), so if something 
goes wrong, I find out about it right away, and it's pretty easy to 
figure out which package was the culprit.

After every upgrade, I run revdep-rebuild (of course with --pretend firt, 
or with --ask) and rebuild what's necessary (which is FAR less with as-
needed in LDFLAGS than it would be otherwise, but OTOH, the --upgrade --
deep means more frequent library upgrades, thus triggering revdep-
rebuilds in some cases).  The --deep --newuse on my upgrades by default 
definitely helps here too, as it helps keep the dependencies sorted out 
that would otherwise get screwed up due to USE flag changes not being 
reflected in what's actually installed.

I also run emerge --depclean (--ask or --pretend first) every time after 
the upgrade, and then another revdep-rebuild if I removed anything, just 
to be sure it didn't leave any dependency holes.

Of course I also do the etc-update, whether portage tells me to or not, 
just to be sure.

I expect I've saved myself a LOT of trouble over the years, due to a few 
basics like the above sysadmin policies.  With a modern multi-core CPU 
and at least a couple gigs RAM, Gentoo really isn't all that hard to keep 
up, provided you are serious enough about sysadminning to learn how to 
play it smart, not rough.  But that last bit is critical.  Gentoo 
provides the tools and manages the ebuilds, plus a good amount of 
documentation.  But it's not about hand-holding.  Gentoo expects users to 
be able to read docs and learn how to take best advantage of the tools 
provided.  If you're not ready to do that, Gentoo's really not the 
distribution for you.  I read that Ubuntu's pretty decent at making 
things brainless.  That may well be a better choice for those who aren't 
serious enough about their sysadminning to learn what the provided tools 
are and how to use them to best effect.

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