Ian Stakenvicius wrote:
"Such data is locally generated ... The application must be able
to regenerate or restore the data."
emerge --sync <-- regenerates/restores the portage tree
Perhaps my English is too poor, but IMHO
download != regenerate/restore.
Indeed, the FHS also emphasizes only the *time* which it costs
to regenerate the data in /var/cache and that it can be deleted
without data loss (e.g. if your filesystem runs full).
However, if you would do this e.g. on a laptop because you
blindly trusted FHS you may have a lot of problems: Not only
can it be quite expensive to "regenerate" the data
(e.g. if you have to pay a lot for the bandwidth where you
currently are), it might even be impossible if you have no
internet connection at all or e.g. if you realize only after
the deletion that you would have to (re)emerge some package to
make the internet connection work (e.g. because you did not
revdep-rebuild before).
(And, yes, if you deal with distdir carefully, there are several
occassions when you might want to (re)emerge a package even if
you have no or only very limited internet connection; not only for
revdep-rebuild but also e.g. if you need to change certain USE-Flags.)
Of course, an experienced user knows and can care about this all,
but an experienced user will choose the location anyway as he needs:
We are speaking about the default which should mainly help also the
less experienced user.
download-restricted data whose sole location is in a cache dir is a
decision made by the user.
If you make /var/cache/... the default, this suggests the wrong
decision to the user. At least, it should be documented then in
a prominent place that the default path where the data is
required is probably not the appropriate path to keep it
(which IMHO is a bit strange).
[...] PORTAGE_RO_DISTDIR [...] Maybe it would be pertinent to
suggest and/or include a default path for this?
This would be a good idea anyway, also because of theoretically
possible name collisions in distdir.
Martin
