Date: Tue, 26 Jun 2012 10:42:06 -0500 From: Eric van Gyzen <eric@vangyzen.net> To: Tim Kientzle <tim@kientzle.com> Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no>, Simon Gerraty <sjg@juniper.net>, freebsd-arch@freebsd.org Subject: Re: Allow user install Message-ID: <4FE9D84E.7080402@vangyzen.net> In-Reply-To: <C31B93F4-674C-4183-9F3F-5F7C48980204@kientzle.com> References: <20120626063017.D05DA58081@chaos.jnpr.net> <86wr2uwdgf.fsf@ds4.des.no> <C31B93F4-674C-4183-9F3F-5F7C48980204@kientzle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 06/26/2012 10:18, Tim Kientzle wrote: > > On Jun 26, 2012, at 3:54 AM, Dag-Erling Smørgrav wrote: > >> Simon Gerraty<sjg@juniper.net> writes: >>> The patch below is a step towards supporting unprivileged buildworld >>> etc. Eg. >> >> Wow, this is really cool - and long overdue. >> >> I've been thinking for a while that some bor^H^H^Henterprising soul >> should hack install(1) so that if a specific environment variable is >> set, it writes the file to a tarball instead of writing it to disk. >> Unfortunately, there would still be a ton of ${LN} etc. that would need >> to be handled somehow. > > Better idea: have the build write a textual description of the > tar entries. That description can then be fed to tar to build > the actual tarball. > > The description format that tar already supports is a variant > mtree format borrowed from NetBSD. Each line specifies > the tar entry fields (filename, owner, permissions, etc) and > the filename where the file contents are stored. Simon: Thank you for working on this and contributing it. I expect it will help a lot of people...including me. :) Tim's idea sounds great, and would cover several use-cases. Specifically, it leaves the build artifacts in the usual places so other, later builds can build against them, whereas writing the artifacts directly to a tar file does not. Building a manifest would also be very handy, and even necessary for correct packaging of the artifacts from an unprivileged build, where the on-disk meta data are not "correct". I'm already doing something like this at $WORK, but not using buildworld/installworld (to my dismay). I manually maintain an mtree file which gets fed to makefs to build an mfsroot. Although I like the fascist control of this method, it's more work to maintain. Automation is good. Eric
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FE9D84E.7080402>