Date: Wed, 9 Oct 2013 10:33:38 -0400 (EDT) From: Benjamin Kaduk <kaduk@MIT.EDU> To: Lyndon Nerenberg <lyndon@orthanc.ca> Cc: freebsd-current@freebsd.org Subject: Re: rcs Message-ID: <alpine.GSO.1.10.1310091031460.16692@multics.mit.edu> In-Reply-To: <316CC412-A884-4E23-95D5-8565872FC844@orthanc.ca> References: <77307DF8-637D-4295-BF47-8742F1552CE8@orthanc.ca> <20131008031517.GA31864@troutmask.apl.washington.edu> <60177810-8DC4-4EA3-8040-A834B79039D2@orthanc.ca> <52538EDC.2080001@freebsd.org> <52541202.3010707@mu.org> <CAOjFWZ4heSgKLr0VHHKnohajt0qFg%2BSL4k2n4JqTUCuRuTXieA@mail.gmail.com> <316CC412-A884-4E23-95D5-8565872FC844@orthanc.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
Going off on a slight tangent... On Tue, 8 Oct 2013, Lyndon Nerenberg wrote: > > For this to work in a disconnected environment, you need a ports tree > with a fully populated distfiles/ directory. The hack we came up with > was to put a FreeBSD host on the external network, on which we ran a > script once a week or so that would do the something like 'portsnap > fetch update; portsclean -DD; for in in /usr/ports/*/*; (cd $i && make > fetch); done'. I just reviewed a documentation patch which was noting that 'make fetch' can be done in a category directory or even in /usr/ports itself. Maybe a little more reliable than the shell loop. -Ben Kaduk > That would give us a (mostly) populated /usr/ports/distfiles. We would > then rsync /usr/ports from the public machine onto a USB drive. That > drive would then be disconnected from the public machine and attached to > an internal file server, and its /usr/ports rsynced to the file server's > /usr/ports.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.GSO.1.10.1310091031460.16692>