/var/cache/portage/distfiles
/var/cache/portage/repositories/gentoo
/var/cache/portage/repositories/{sunrise,kde,gnome,whatever,layman,grabs}
/var/db/portage/repositories/{non-cache,repo,names,go,here}
+1
-1
The subdirs are too deeply nested.
There is a practical advantage of having the main gentoo tree
and all overlays in the same directories which was not mentioned yet:
In this way it is easy to put them in a common filesystem appropriate
for this type of data (e.g. squashfs+aufs or whatever).
The same argument holds if you want to export the tree to several
systems: Probably all overlays should then be exported as well.
However, I have strong objections against using /var/cache at all:
FHS explicitly states:
"Such data is locally generated ... The application must be able to
regenerate or restore the data."
In my opinion it is rather clear that "regenerate" does not mean
"download". Not to speak about download-restricted data which
"the application" is certainly not able to regenerate.
(That locally maintained overlays do not fall into this category
is clear anyway; but again, it would be nice to have these possibly
on the same filesystem as all other ebuilds: Especially compressing
or other deduplicating filesystem would treat this better).
Therefore I would prefer another location.
Of course, on many systems, something under /srv might be the appropriate
place (especially if the tree should be exported); this should perhaps be
suggested to the user, although it is probably not a good idea to make
this the default, because any default can just be plain wrong for the
user's system.
What is really so bad about the current location under /usr as default?
Or maybe only split somewhat differently than currently like e.g.
/usr/portage/{gentoo,sunrise,...,local}
/usr/distiles
This would avoid the deep nesting, although it would allow a
common filesystem for the data of the same type.
As far as I can see, the argument against /usr/... is only that the
data is not "constant". But actually, it is as constant as all
other data in /usr: Usually emerge --sync is only called to do
an emerge afterwards which means that the data only needs to be
modified if you intend to modify /usr anyway...
Martin
