1 |
On Wed, Mar 28, 2012 at 2:53 PM, Christoph Mende <angelos@g.o> wrote: |
2 |
> |
3 |
> I believe it's /var/lib/<name>. Here's what FHS says: |
4 |
> /var/cache is intended for cached data from applications. Such data is |
5 |
> locally generated as a result of time-consuming I/O or calculation. |
6 |
> The application must be able to regenerate or restore the data. Unlike |
7 |
> /var/spool, the cached files can be deleted without data loss. |
8 |
> |
9 |
|
10 |
I can do rm -rf /usr/portage ; mkdir /usr/portage ; emerge --sync and |
11 |
it will work just fine, I think. |
12 |
|
13 |
That really does point to cache. The only thing different from a |
14 |
browser cache is that portage doesn't automatically refresh it. |
15 |
|
16 |
distfiles and packages are the same (well, depending on where you get |
17 |
your binpackages from, that might or might not be a cache per-se - if |
18 |
you're just using FEATURES=buildpkg then you can do an emerge -e world |
19 |
and get it back). |
20 |
|
21 |
> And: |
22 |
> /var/lib/<name> is the location that must be used for all distribution |
23 |
> packaging support. |
24 |
> |
25 |
|
26 |
I think that things like the local list of installed packages belongs |
27 |
in this category. It is a bit debatable how the tree fits into this. |
28 |
|
29 |
However, this really is bikeshedding. Sure, /usr isn't ideal, but |
30 |
unless we actually start supporting some use case where it doesn't |
31 |
work so well in the future, I doubt we'll ever see it move. Plus, |
32 |
there is even a case for keeping it in /usr in the Fedora-envisioned |
33 |
/usr-is-ro world. You could have a complete installation and a |
34 |
portage tree that it was generated from all snapshotted there. Sure, |
35 |
maybe /usr/lib or /usr/share might make more sense then, but again, I |
36 |
don't see it changing unless it actually results in a real benefit to |
37 |
users. |
38 |
|
39 |
Rich |