On 3 January 2014 06:02, Luis Ressel <ara...@aixah.de> wrote:
> These are good arguments. Just to be clear: Would you favor if the
> default setup did this separation? I personally also like the idea, but
> I'd prefer to leave the default at "one distdir for *", and just make
> it configurable via the proposed variables.
>
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
