Gentoo Archives: gentoo-portage-dev

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-portage-dev@l.g.o
Subject: [gentoo-portage-dev] Of modules, repos.conf, and metadata caches
Date: Fri, 09 Apr 2010 16:39:07
1 I've had a number of portage questions that don't seem dealt with so well
2 in the docs, that have been brewing in my head for some time. If these
3 are answered somewhere, feel free to point me at the docs, but if I don't
4 know where they are, they very likely need rather higher visibility.
5 Else, perhaps the docs don't exist or need seriously expanded and updated.
7 1) Modules. For years I've seen fleeting mentions of alternative caching
8 modules, etc. Back when I saw the first references, I figured there must
9 be some documentation about them somewhere. But from then to now I've yet
10 to see any sort of proper documentation listing what's available, and why
11 people might wish to use these modules.
13 What little doc hint I've seen is in the portage (5) manpage under /etc/
14 portage/modules, but that's really all it is, is a hint. "If you use
15 something like the sqlite module", etc, doesn't give me any help with
16 where I can find a list of these modules, why I might want to use them,
17 and what the down sides (there must certainly be some as they aren't the
18 default!) might be.
20 2) My understanding of metadata caching is woefully outdated and I'm in
21 need of a clue!
23 Basically, somewhere, there should be a document that explains in "plain
24 English" the interplay between FEATURES=metadata-transfer,
25 $PORTDIR/metadata/cache, layman, eclass priorities, $PORTDIR/metadata/
26 layout.conf (doesn't exist here, I gather that's funtoo or some such
27 related? portage manpage could say it doesn't exist in the main gentoo
28 tree or something), /etc/portage/repos.conf, emerge --metadata, emerge
29 --regen, etc, etc...
31 When exactly should FEATURES=metadata-transfer be on, when should it be
32 off? Do overlays potentially with eclasses affect the answer? For
33 someone not using layout.conf/repos.conf, do the main tree eclasses
34 override everything or is there a preference for in-same-repo-eclasses?
35 Does emerge --regen still need run after a sync for if overlays with
36 eclasses are used, even if there's no layout.conf/repos.conf to change
37 ordering?
39 3) This probably relates to my failure to properly understand #2, but it's
40 a special-case, so...
42 Here, I'm running an ~amd64 no-multilib profile for my main machine.
43 However, it also has a 32-bit chroot image, built by following the gentoo/
44 amd64 32-bit chroot guide with a few slight mods, that is where I build
45 the image that then gets ssh/rsynced to my (32-bit-only ~x86) netbook,
46 which neither builds anything nor even has access to a gentoo tree, as
47 everything's prebuilt and then rsynced from the ~x86 image chroot on my
48 main machine.
50 On the main machine, both the native system and the 32-bit chroot share
51 the same gentoo tree and overlays using a mount-bind into the 32-bit
52 chroot, but of course, /etc/ is separate, so therefore /etc/portage,
53 make.conf, and make.profile -- totally separate portage configs.
54 Similarly, separate /var/ and therefore separate portage databases.
56 The problem I've noticed is that after syncing (both the gentoo tree and
57 the layman overlays) and doing the emerge --regen, which at least used to
58 be required, on my main system, emerge dependency calculation seems to go
59 reasonably fast. Not so in the chroot, which seems to take far far
60 longer, and which doesn't improve much after the first run with the files
61 in in-memory disk cache, as the main system does. It's as if it's not
62 properly metadata-cached. But what bit am I missing and how do I correct
63 it? Do I just need to emerge --metadata? emerge --regen on the chroot as
64 well, even with both the gentoo tree and overlays mount-binded so
65 identical in both? Something else? Maybe the 32-bit is /that/ much
66 slower than 64-bit, even on the same machine?
69 Some sort of proper documentation allowing me (and others. of course) to
70 make proper heads and tails of all this is desperately needed. If it's
71 available already, then certainly we need a more highly visible pointer to
72 it, as I honestly haven't the foggiest and I'd not exactly call myself a
73 Gentoo newbie. =:^/
75 --
76 Duncan - List replies preferred. No HTML msgs.
77 "Every nonfree program has a lord, a master --
78 and if you use the program, he is your master." Richard Stallman