Alex Efros posted on Sat, 20 Oct 2012 23:07:40 +0300 as excerpted:
> Hi!
>
> On Sat, Oct 20, 2012 at 08:07:31PM +0200, Dominique Michel wrote:
>> USE="-consolekit -policykit -udisks -upower"
>
> I'm using fluxbox, but, of course, I need ability to run gnome and kde
> applications (but not gnome/kde itself). Last time I tried to switch off
> these USE-flags it doesn't work. Best I got is:
>
> /etc/make.conf:
> USE="${USE} -policykit -upower"
> /etc/portage/package.use
> # required by udisks
> sys-fs/udev extras gudev hwdb
> # required by polkit, consolekit
> sys-auth/pambase consolekit
> # required by polkit, udisks, clementine
> sys-auth/consolekit policykit
FWIW, as my gentoo experience lengthens, I've gotten *MUCH* tighter with
my installed-packages and USE flags policy.
I run a kde desktop, but have this in my global USE file[1]:
-consolekit -policykit -udisks -udisks2 -upower
Also given my kde4 desktop it's worth noting:
-raptor -redland -semantic-desktop -virtuoso
(Of course that means no kdepim packages at all. I got fed up with
akonadi problems and switched to the gtk-based claws-mail after nearly a
decade on kmail! That allowed me to kill kmail and akonadi, which
allowed me to kill semantic-desktop for all of kde, which allowed me to
kill rasqal, redland, virtuoso, soprano... I did it mainly to get rid of
akonadi and the problems it brought, but WOW, the kde4 desktop was faster
without all that extra bloatware! And I had already turned off nepomuk
and strigi too, and it was STILL dramatically faster when kde was built
without that junk! Sort of reminds me of all those MSWormOS users and
how surprised they often are to learn how badly the malware was affecting
system performance once it's cleaned up. Yes, I DID just compare the
semantic-desktop crap to malware!)
But: USE=udev
No udisks (1 or 2), upower, consolekit or policykit installed.
But, I actually prefer manual mounting of removables (significantly safer
that way!), etc, and the fact that automount functionality requires
udisks, which (in v1) ultimately pulls in lvm2, and I'm NOT interested in
having that on my system[2], so while I tolerated it for awhile,
ultimately I got rid of it.
Meanwhile, the below is an admitted rather long tangent, but readers may
find this output from emerge --depclean ($>> is the last line of my
triple-line customized bash $PS1 prompt) rather interesting indeed, and
it DOES continue the "tightened up system" policy theme I presented above:
$>>emerge --depclean -p
[snip the standard boilerplate]
!!! You have no system list.
!!! Proceeding is likely to break your installation.
[more boilerplate]
Packages installed: 865
Packages in world: 0
Packages in system: 0
Required packages: 865
Number to remove: 0
Empty system warning, empty world, yet 865 required packages? WTF?
The empty @system set warning is accurate; the empty world not quite so,
tho it's anything but standard. Here's the explanation:
World first, as it's easier. =^)
I'm running the (still masked) portage-2.2-alpha series for sets support,
which (AFAIK) hasn't yet hit the 2.1 series. My world file is INDEED
empty, but that's because I took advantage of sets support to break up
the long and unsorted world list into a bunch of sets, each of which is
listed in the world_sets file. (That's comparable to what I did with
make.conf, as noted in footnote [1] from the mention of my global USE
file.)
So my /var/lib/portage/world_sets file lists sets like (jed are my
initials, used here to indicate that they are my custom sets, distinct
from for example the sets that the kde overlay ships, tho my custom kde
sets are simply the sets from the overlay, with various packages
commented out, I diff them against the overlay set twice a year when I
upgrade to the next kde 4.x version minor, making adjustments as
necessary then):
@jed.admin
@jed.kde.base.kdegames
@jed.portage
That's just picking three from the list of about two dozen.
Here's the contents of my @jed.portage set as an example:
$>>cat /etc/portage/sets/jed.portage
app-portage/eclass-manpages
app-portage/esearch
app-portage/gentoolkit
app-portage/layman
app-portage/mirrorselect
app-portage/portage-utils
app-doc/pms
So while my world file is empty, my world_sets file has about two dozen
sets listed, each of which contains its own list of packages I want that
sort into that category. Yes, my world file is empty, but the @world /
set/ is not empty. But the depclean summary hasn't yet been updated for
sets. I filed a feature-request-bug[3] on that some time ago, but
obviously it's down Zac's priority list quite a way, until such time as
they decide to introduce proper sets support to an unmasked portage.
Worst-case, they drop the still experimental sets feature instead, and I
have to recombine all the packages listed in my individual sets into one
big world file again. No big deal tho sets support is nice and I'd miss
it. At least I've been able to use sets in the mean time.
OK, that explains the "empty" world, the world _file_ is empty, but not
the world_sets file and thus not @world, but the depclean summary doesn't
know about world_sets yet.
What about that empty @system warning?
The technical information's available in the portage (5) manpage, but it
comes down to this: /etc/portage/profile/* files can be used to override
the normal tree profile where a gentoo users finds it necessary to do
so. Basically it gets applied on top of the normal cascading profile in
the tree, adding or subtracting from it just as the contents of the
make.profile dir override the contents of its cascaded parents.
More specifically, the packages file contains entries like this (with or
without the negation, but with the *):
-*sys-devel/make
-*>=sys-devel/patch-2.6.1
Each (un-negated) starred package atom found in the packages file in one
of the cascaded profile dirs adds that package to the @system set.
Negating the entry removes a package from @system that was added by one
of the cascading parents.
Now here's the deal. There are two purposes that the @system set
fulfills. First, the list of packages in @system is used by catalyst to
create the stage tarballs used to bootstrap a gentoo system at initial
installation. Basically, it's the list of packages found in a stage3.
Second, once a gentoo system is installed and running, the list of
packages in @system form a core set of basic dependencies that can be
assumed to be installed, so they can be omitted from an ebuild's
dependencies list, dramatically shortening the dependencies list and
decreasing the maintenance burden both for individual package maintainers
since they have a core set of packages that can be assumed to be
installed, and for core system and arch maintainers, since that core list
is nicely centralized, thus much easier to change that it would be to
edit thousands of individual ebuild dependencies.
For the gentoo user, among other things, if you mistakenly try to unmerge
something in the system set, portage gives you a much stronger warning
than it would otherwise, since it's very possible doing so will break the
system beyond easy recoverability, forcing a boot to a rescue disk or
backup in ordered to fix the problem.
But there is a very practical non-zero cost to having a package in
@system. Portage is more careful with these packages and tends to merge
them one at a time, thus breaking emerge's parallel merge ability and the
--jobs and --load-average options that control it, when merging an
@system package or a dependency of one, forcing portage back to the bad
old days of serialized one-package-at-a-time merging. For people with
even a quad-core system and enough memory to nicely handle multiple
merges who have accordingly enabled parallel merging using the --jobs and
--load-average options, then, any package that's in @system or a
dependency of something in @system, dramatically slows down system
updates, and even more so, the emerge --empty-tree @world that many
people like to do after a major gcc upgrade or change to CFLAGS/CXXFLAGS/
LDFLAGS. Keeping @system as small as possible directly affects the speed
at which updates and particularly --empty-tree rebuilds complete!
So the @system package list has two purposes, only one of which actually
matters once you're beyond the stage-3 point of an install, while every
package on that list and all its dependencies have a dramatically
increased cost in terms of merge time on a modern multicore system, since
those packages can't take advantage of portage's parallel emerges ability.
Once a user has been on gentoo awhile and knows his way around the system
well enough that he's unlikely to make the mistake of unmerging a package
he well enough knows is critical, thus making that extra warning for such
a mistake unnecessary, the cost of that @system list begins to look
bigger and bigger in relation to the actual benefit it continues to
provide.
My first gentoo install was 2004.0... 8.5 years ago. If I'm sure enough
about an emerge -C to do it in the first place, that extra @system
warning isn't going to stop me, so I might as well not have to deal with
its cost.
But here, an emerge --pretend --emptytree @system wanted to remerge 300+
packages! I forgot how many were actual @system packages, but most of
them were dependencies. That's a *LOT* of packages for portage to be
forcing to one-at-a-time merging!
So at first I tried whittling down the number of @system deps by tweaking
USE flags. That did drop the total some, but not enough! And trying to
sort out individual package.use exceptions was getting complex!
Simple enough solution, be rid of the whole @system list!
emerge --pretend @system provided a list of package in that set, without
dependencies. First I did an emerge --pretend --depclean to ensure there
was nothing it wants to remove with the existing system set that I needed
to decide about. (There wasn't, I routinely run revdep-rebuild and
emerge --depclean after I'm finished updating. Everything was in world,
or in my case in the world_sets, that needed to be. No package cruft
left hanging!)
Then I took that emerge --pretend @system list and create /etc/portage/
profile/packages negating entries for each of them. =:^)
Reran emerge --pretend @system. What was this? Two packages still in
@system along with 200+ dependencies (--emptytree lists the deps too,
without it, only the actual @system packages are listed)! WTF?
While I tried to figure that out, I played around with USE flags some
more and with just those two packages in @system, I was able to get the
total @system with deps down to 120 or so. MAJOR PROGRESS, especially
when I had started with 300+, and still had 200+ with only two packages
in @system. BUT NOT GOOD ENOUGH!
Meanwhile, while I tried to figure out what was going on there, I did
another --depclean --pretend to see what packages in @system weren't
still protected as dependencies of something in @world. Turns out most
of them were already dependencies of something, so only a few packages
came up to be depcleaned.
And actually, several of those were virtuals (example, virtual/editor,
default provider nano). For most of those, I already had the package
that I wanted to fill that virtual in @world (in one or another of my
custom @jed.* sets), so unmerging the virtual wasn't going to hurt
anything because the package I wanted to fill that virtual was still
installed and in @world. So I unmerged the unnecessary virtuals.
For the handful of others, after figuring out which @jed.* set I wanted
each one in, I added it there. After that a --depclean --pretend came up
clean again and the installed package list was stable, tho @system along
with its depends was still too big for comfort.
I let it sit at that point for a few days, while I tried to figure out
where the other two @system entries were coming from. At first I thought
they must be hard-coded, which made some sense for the one, baselayout-2.
But the other one was patch, and it just made no sense that /patch/, of
ALL things, would be hardcoded, but things like gcc or sed and grep
weren't.
Turns out there was a simple explanation. Those two @system package
entries weren't simply generic entries like this:
*sys-apps/baselayout
*sys-devel/patch
They actually appeared with version specifiers like this:
*>=sys-apps/baselayout-2
*>=sys-devel/patch-2.6.1
So the generic negation wasn't cutting it. I had to do this, negating the
exact same entries that were added by the in-tree profile:
-*>=sys-apps/baselayout-2
-*>=sys-devel/patch-2.6.1
Viola! THAT DID IT! TOTALLY ZEROED OUT @system LIST!! =:^)
Repeated the --depclean --pretend but those last couple packages were deps
of something already in @world so they didn't need added.
So now I have an entirely empty @system, and packages parallel-merge much
more efficiently. =:^)
I was so happy, I took the opportunity to do a full emerge --emptytree
@world, something I hadn't done since upgrading cpu/gpu/mobo/ram to a 6-
core bulldozer and changing CFLAGS/CXXFLAGS accordingly, back in July,
tho I had been keeping up with updates including a kde bump, so it wasn't
too bad.
Between the better parallel merging of the empty @system and the upgrade
from a dual-dual-core opteron 290 @2.8 (so four cores of k8 tech) on the
old system, to the new six-core buldozer (fx6100) slightly overclocked to
3.6, I was rather happy with the full --emptytree @world merge time
improvement. =:^)
In fact, I was so happy with that, that I updated my 32-bit chroot on the
same machine, where I build the image I rsync to the (32-bit-only atom
n270) netbook, did an upgrade there, something that I hadn't done in a
year and a half so it was a bit complicated to sort out but I managed,
negated its entire @system and adjusted its custom sets appropriately,
and then to be sure, did an emerge --emptytree @world there as well. =:^)
Bottom line, an empty @system set really does make a noticeable
difference in parallel merge handling, speeding up especially --emptytree
@world rebuilds but also any general update that has a significant number
of otherwise @system packages and deps, dramatically. I'm happy. =:^)
---
[1] Global use file: I take advantage of the make.conf source statement
to source a bunch of individual files. make.conf itself simply sources a
master file (dead easy to recreate make.conf that way if it gets deleted/
overwritten), which in turn sources a bunch of individual files. ($>> is
the third line of my customized bash $PS1 prompt, the first is a blank
line and the second is deleted for posting.)
$>>cat /etc/portage/make.conf
source /etc/portage/make/master
*$>>cat /etc/portage/make/master
source /etc/portage/make/cflags
source /etc/portage/make/collision-ignore
source /etc/portage/make/features
source /etc/portage/make/fs
source /etc/portage/make/layman
source /etc/portage/make/ldflags
source /etc/portage/make/log
source /etc/portage/make/makeopts
source /etc/portage/make/mirrors
source /etc/portage/make/net
source /etc/portage/make/use
source /etc/portage/make/use.expand
source /etc/portage/make/other
So I have a file, /etc/portage/make/use, that contains only my globally
applied USE flags. There's another for CFLAGS/CXXFLAGS, another for
LDFLAGS, another for the filesystem (fs) settings, another for MAKEOPTS,
another for FEATURES, etc.
[2] LVM2: I tried lvm2 at one point, and decided the additional
complexity and negative effect on my confidence in my own ability to
sanely manage disaster recovery and restore access to my data, was
nothing I was interested in, and it's not worth having around on the
system just to handle automount, either!
FWIW I DID run with an md/raid configured system for awhile altho I
recently upgraded and didn't have money for another disk so am not
running it now, but md/raid was nice! =:^)
[3] depclean summary: world_sets line request
Clear-Text:
http://bugs.gentoo.org/show_bug.cgi?id=298298 Secure:
https://bugs.gentoo.org/show_bug.cgi?id=298298 --
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