Yeah, that seems fine to have them all default to the same directory, and document that end users can set these variables and get certain reactions.

The only ambiguity I think creeps in is when you're say, jdk, and you're telling users to download a file to a directory somewhere, you want to tell them "Download to ${DISTDIR_NOFETCH}" , which may not necessarily be available in all PMS implementations, and there's no real way around that.

As it is,we have the best I could expect, pkg_nofetch() + error message, because you can't really give a generic response to RESTRICT=fetch , because fetch restrictions are not straight forward to resolve, and the only plausible way to enhance on this circumstnace would be to have a standard PMS feature that appended to the pkg_nofetch() with a list paths it was expecting to exist.

Not to mention, supporting "Check all of $DISTDIR/$NOFETCH/$NOMIRROR" would be a nightmare, because it appears lots of ebuilds manually use the $DISTDIR variable, and would have to be ported somehow to use the new variables.

find /usr/portage/ -name "*.ebuild" -print0 | xargs -0 -P3 grep 'DISTDIR'  -l | wc -l

> 1523

So essentially, the feature set I've suggested have rather complex implications that I can't see being entirely viable without it being a future EAPI feature.

There's ways of smoothing this out in portage land by dynamically changing where DISTDIR points, but thats a similarly ugly problem.

--
Kent