I've had a number of portage questions that don't seem dealt with so well
in the docs, that have been brewing in my head for some time. If these
are answered somewhere, feel free to point me at the docs, but if I don't
know where they are, they very likely need rather higher visibility.
Else, perhaps the docs don't exist or need seriously expanded and updated.
1) Modules. For years I've seen fleeting mentions of alternative caching
modules, etc. Back when I saw the first references, I figured there must
be some documentation about them somewhere. But from then to now I've yet
to see any sort of proper documentation listing what's available, and why
people might wish to use these modules.
What little doc hint I've seen is in the portage (5) manpage under /etc/
portage/modules, but that's really all it is, is a hint. "If you use
something like the sqlite module", etc, doesn't give me any help with
where I can find a list of these modules, why I might want to use them,
and what the down sides (there must certainly be some as they aren't the
default!) might be.
2) My understanding of metadata caching is woefully outdated and I'm in
need of a clue!
Basically, somewhere, there should be a document that explains in "plain
English" the interplay between FEATURES=metadata-transfer,
$PORTDIR/metadata/cache, layman, eclass priorities, $PORTDIR/metadata/
layout.conf (doesn't exist here, I gather that's funtoo or some such
related? portage manpage could say it doesn't exist in the main gentoo
tree or something), /etc/portage/repos.conf, emerge --metadata, emerge
--regen, etc, etc...
When exactly should FEATURES=metadata-transfer be on, when should it be
off? Do overlays potentially with eclasses affect the answer? For
someone not using layout.conf/repos.conf, do the main tree eclasses
override everything or is there a preference for in-same-repo-eclasses?
Does emerge --regen still need run after a sync for if overlays with
eclasses are used, even if there's no layout.conf/repos.conf to change
3) This probably relates to my failure to properly understand #2, but it's
a special-case, so...
Here, I'm running an ~amd64 no-multilib profile for my main machine.
However, it also has a 32-bit chroot image, built by following the gentoo/
amd64 32-bit chroot guide with a few slight mods, that is where I build
the image that then gets ssh/rsynced to my (32-bit-only ~x86) netbook,
which neither builds anything nor even has access to a gentoo tree, as
everything's prebuilt and then rsynced from the ~x86 image chroot on my
On the main machine, both the native system and the 32-bit chroot share
the same gentoo tree and overlays using a mount-bind into the 32-bit
chroot, but of course, /etc/ is separate, so therefore /etc/portage,
make.conf, and make.profile -- totally separate portage configs.
Similarly, separate /var/ and therefore separate portage databases.
The problem I've noticed is that after syncing (both the gentoo tree and
the layman overlays) and doing the emerge --regen, which at least used to
be required, on my main system, emerge dependency calculation seems to go
reasonably fast. Not so in the chroot, which seems to take far far
longer, and which doesn't improve much after the first run with the files
in in-memory disk cache, as the main system does. It's as if it's not
properly metadata-cached. But what bit am I missing and how do I correct
it? Do I just need to emerge --metadata? emerge --regen on the chroot as
well, even with both the gentoo tree and overlays mount-binded so
identical in both? Something else? Maybe the 32-bit is /that/ much
slower than 64-bit, even on the same machine?
Some sort of proper documentation allowing me (and others. of course) to
make proper heads and tails of all this is desperately needed. If it's
available already, then certainly we need a more highly visible pointer to
it, as I honestly haven't the foggiest and I'd not exactly call myself a
Gentoo newbie. =:^/
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