1 |
>>> /var/cache/portage/distfiles |
2 |
>>> /var/cache/portage/repositories/gentoo |
3 |
>>> /var/cache/portage/repositories/{sunrise,kde,gnome,whatever,layman,grabs} |
4 |
>>> /var/db/portage/repositories/{non-cache,repo,names,go,here} |
5 |
> |
6 |
>> +1 |
7 |
> |
8 |
> -1 |
9 |
> |
10 |
> The subdirs are too deeply nested. |
11 |
|
12 |
There is a practical advantage of having the main gentoo tree |
13 |
and all overlays in the same directories which was not mentioned yet: |
14 |
|
15 |
In this way it is easy to put them in a common filesystem appropriate |
16 |
for this type of data (e.g. squashfs+aufs or whatever). |
17 |
The same argument holds if you want to export the tree to several |
18 |
systems: Probably all overlays should then be exported as well. |
19 |
|
20 |
However, I have strong objections against using /var/cache at all: |
21 |
FHS explicitly states: |
22 |
|
23 |
"Such data is locally generated ... The application must be able to |
24 |
regenerate or restore the data." |
25 |
|
26 |
In my opinion it is rather clear that "regenerate" does not mean |
27 |
"download". Not to speak about download-restricted data which |
28 |
"the application" is certainly not able to regenerate. |
29 |
(That locally maintained overlays do not fall into this category |
30 |
is clear anyway; but again, it would be nice to have these possibly |
31 |
on the same filesystem as all other ebuilds: Especially compressing |
32 |
or other deduplicating filesystem would treat this better). |
33 |
|
34 |
Therefore I would prefer another location. |
35 |
|
36 |
Of course, on many systems, something under /srv might be the appropriate |
37 |
place (especially if the tree should be exported); this should perhaps be |
38 |
suggested to the user, although it is probably not a good idea to make |
39 |
this the default, because any default can just be plain wrong for the |
40 |
user's system. |
41 |
|
42 |
What is really so bad about the current location under /usr as default? |
43 |
Or maybe only split somewhat differently than currently like e.g. |
44 |
/usr/portage/{gentoo,sunrise,...,local} |
45 |
/usr/distiles |
46 |
|
47 |
This would avoid the deep nesting, although it would allow a |
48 |
common filesystem for the data of the same type. |
49 |
|
50 |
As far as I can see, the argument against /usr/... is only that the |
51 |
data is not "constant". But actually, it is as constant as all |
52 |
other data in /usr: Usually emerge --sync is only called to do |
53 |
an emerge afterwards which means that the data only needs to be |
54 |
modified if you intend to modify /usr anyway... |
55 |
|
56 |
Martin |