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
