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>