[gentoo-dev] Re: About using USE flags to pull in needed RDEPENDs being discouraged by devmanual

[Duncan]

Pacho Ramos posted on Sat, 16 Jun 2012 18:30:55 +0200 as excerpted:

>> > 2. If user emerges ppp, it will be recorded in world file and, then,
>> > if in the future he removes bluez, emerge --depclean want clean no
>> > longer needed ppp and then, people end up with a lot of packages they
>> > needed to manually emerge some year but that they problem no longer
>> > need at all.
>>
>> It's not our job to maintain users world files.
>>
>>
>>
> Even for me I tend to periodically check world files of machines I
> maintain, and it's tedious, we shouldn't promote people to easily
> contaminate their world files. Currently, most people will end up having
> a lot of unneeded packages installed in their systems after years of
> usage due this way of happily telling people to install some random
> packages to get extra support.

Looking at the broader picture, the problem of extraneous packages in the 
world file has always concerned me.  If it were to be done over again, 
and I think Zac would likely agree, emerge would use --oneshot by 
default, so as not to contaminate the world file unnecessarily.  Then 
there'd be a different option (say -2) to add the package to the world 
file if that's what was actually intended.

That's actually how I have my emerge front-end scriptlets/aliases setup 
here.  -1 is the default; if I want it in the world file I use the *2 
script variant, which omits the -1.

But of course changing behavior in mid-stream doesn't work so well, so 
emerge continues to stick stuff in the world file by default.


Meanwhile, one coming solution to this, in portage 2.2 anyway, is sets.  
Since I've been working with kde4 since it was overlay-only and sets-
only, no meta-packages, I've been using sets for quite awhile and it's 
now entirely integrated into how I work with portage.

When I setup my netbook on gentoo, I wanted most of the same setup as on 
my main machine, but with some differences, so I had to go thru the main 
machine's world file and pick and choose what I needed.

What I quickly realized is that my kde packages were already nicely 
categorized into sets, so all I really needed to do was split up the rest 
of the world file into a bunch of other sets, by category.  So for 
instance:

$>>cat /etc/portage/sets/jed.dev
dev-util/ccache
dev-util/desktop-file-utils
dev-vcs/git
sys-devel/bin86
sys-devel/gcc
sys-devel/gdb


I have 24 such sets including my (customized) kde sets.  All packages 
formerly listed in the world file are found in these sets, instead, and 
of course the sets are in turn listed in /var/lib/portage/world_sets.

My world file is normally entirely empty, tho I do use it occasionally 
for packages I haven't decided whether I want to keep or not, but want to 
protect from --depclean, which I run after each update.  So my world file 
serves as a kind of package purgatory, until I decide whether it's going 
to be a part of my normal system, or removed.

The sets, meanwhile, break the former world file down into much more 
manageable categorized chunks, each of which is short enough and 
categorized specifically enough that if a package is no longer needed, it 
immediately sticks out like a sore thumb, as it's not lost among the 
noise of hundreds of "twisty packages, all different". =:^)


While not a direct solution to the problem at hand, proper use of sets 
WILL and DOES dramatically ease gentoo world-package administration, 
going a long way toward eliminating crufty world lists simply by allowing 
them to be cut into nice little chunks that can be categorized in ways 
that make sense for an individual site, so the cruft sticks out like the 
sore thumb it can really be, and is thus easily found and removed.


Meanwhile, another bonus of sets is the extra protection it gives you if 
you try to emerge -C something in a sets file (as opposed to the world 
file itself). =:^)  Seeing that warning that the package is in a set and 
can't be directly unmerged is rather like seeing the warning that it's in 
@system, except that user sets are easier to directly manage, and it has 
saved my butt a couple times when I was really too sleepy to be adminning 
the system in the first place.  But it's easy enough to remove (or 
comment) that line from the set, if removal is really intended, and 
that's what would ultimately need to be done anyway, to prevent it 
getting remerged.


Unfortunately, it has begun to look like sets are where baselayout2 and 
openrc were for many years, "forever coming, never getting here", at 
least for stable or even unmasked into ~arch. =:^(

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