1 |
I take it shortly together as Rene didn't catch all and so I was fuzzy: |
2 |
|
3 |
Portage tree has automatically updateable parts, which should not changed by |
4 |
user, and overlay, which will be. Thus, index of this automatic part should |
5 |
be updated only after "emerge --sync". |
6 |
|
7 |
Speedup should contain custom filesystem, which would be called PortageFS, |
8 |
for example. In initial version, PortageFS uses current portage tree and |
9 |
generates additional indexes. |
10 |
|
11 |
So, when you bootup, you have portage tree in /usr/portage. At some point, |
12 |
PortageFS is mounted into the same directory, /usr/portage. It will map real |
13 |
/usr/portage directory into /usr/portage mount point and create some |
14 |
additional folders like /usr/portage/search, which maps files to do real |
15 |
searches. /usr/portage/handler would be a file, where you can write query |
16 |
and read result. It also contains virtual files to check dependancies and |
17 |
such stuff - many things you could use with your scripts. |
18 |
|
19 |
When it's mounted, every change is noticed and indexes will be automagically |
20 |
updated (and sometimes after communication with portage - for example, |
21 |
updates when doing "emerge --sync" should not happen automagically maybe, as |
22 |
it makes things slower. When it's not mounted, you can change user files, |
23 |
but must run some notification script afterwards maybe to rebuild indexes. |
24 |
|
25 |
Indexes are built-in into FS. |
26 |
|
27 |
If PortageFS is not mounted, for example because of some emergency reboot, |
28 |
portage can work without indexes, using real directory instead of this mount |
29 |
point. |