I use fetch-recursive-list to get distfiles to non-networked jails, however I have to move anything using DIST_SUBDIR manually as it just puts them in CWD. Perusing fetch-list I see... DIR=${DIST_SUBDIR};\ CKSIZE=`alg=SIZE; ${DISTINFO_DATA}`; \ case $${file} in \ */*) args="-o $${file} $${site}$${file}";; \ *) args=$${site}$${file};; \ esac; \ ${ECHO_CMD} -n ${SETENV} ${FETCH_ENV} ${FETCH_CMD} ${FETCH_BEFORE_ARGS} $${args} "${FETCH_AFTER_ARGS}" '|| ' ; \ Which looks odd as 'DIR' is never used - was this feature removed or broken by mistake? I would expect (ho ho ho) it to be relatively easy to check if DIST_SUBDIR is set and if so add something like if [ ! -d ${DIST_SUBDIR} ]; then; mkdir ${DIST_SUBDIR}; fi; ( cd ${DIST_SUBDIR} ; .... )
You are right, DIR is not used, it must be a remnant of some other thing. There's some ECHO_CMD missing that would contains a cd ${_DISTDIR}. I'll have a closer look.
A commit references this bug: Author: mat Date: Thu Mar 10 16:48:23 UTC 2016 New revision: 410767 URL: https://svnweb.freebsd.org/changeset/ports/410767 Log: Fix fetch-list. PR: 207875 Sponsored by: Absolight Changes: head/Mk/bsd.port.mk
Is there a way to make it relative directories only? Otherwise it generates absolute paths for cd which makes my use case impossible. ie I want to run 'make fetch-recursive-list >/fetchlist' in a jail, then run this in the host.. cd /path/to/jail/var/ports/distfiles sh /path/to/jail/fetchlist
Well, no, because, then, it would need to parse DIST_DIR to know how to get back to where it started, and such. Your best bet is either to sed -e 's|^cd /usr/ports|cd /some/where/else|' Well, your better bet would be to null mount /usr/ports/distfiles in all your jails so that you have only one copy of each distfile, and it has the same path on the host, and in the jails.
(In reply to Mathieu Arnold from comment #4) I don't think it needs to know that - just use subshells eg.. (cd foo ; fetch XXX || fetch YYY | ....)
No, it has to work wherever it's ran from.
(In reply to Mathieu Arnold from comment #6) So you mean it *has* to have an absolute path? (even though previously it was purely relative)
(In reply to darius from comment #7) > So you mean it *has* to have an absolute path? (even though previously it > was purely relative) Well, previously, it was broken, so I can't say if it was by design... It may, or may not, have worked in the past, if you want to sieve through the history to find out... :-)