Date: Tue, 26 Jun 2012 09:51:01 -0600 From: Warner Losh <wlosh@bsdimp.com> To: Eric van Gyzen <eric@vangyzen.net> Cc: Tim Kientzle <tim@kientzle.com>, freebsd-arch@freebsd.org, Simon Gerraty <sjg@juniper.net>, =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no> Subject: Re: Allow user install Message-ID: <0D02B52A-662A-4A42-A239-A9A5D3ABA403@bsdimp.com> In-Reply-To: <4FE9D84E.7080402@vangyzen.net> References: <20120626063017.D05DA58081@chaos.jnpr.net> <86wr2uwdgf.fsf@ds4.des.no> <C31B93F4-674C-4183-9F3F-5F7C48980204@kientzle.com> <4FE9D84E.7080402@vangyzen.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 26, 2012, at 9:42 AM, Eric van Gyzen wrote:
> On 06/26/2012 10:18, Tim Kientzle wrote:
>>=20
>> On Jun 26, 2012, at 3:54 AM, Dag-Erling Sm=F8rgrav wrote:
>>=20
>>> Simon Gerraty<sjg@juniper.net> writes:
>>>> The patch below is a step towards supporting unprivileged =
buildworld
>>>> etc. Eg.
>>>=20
>>> Wow, this is really cool - and long overdue.
>>>=20
>>> 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.
>>=20
>> 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.
>>=20
>> 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.
>=20
> Simon: Thank you for working on this and contributing it. I expect =
it will help a lot of people...including me. :)
>=20
> 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".
>=20
> 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.
Yea. NetBSD's build already can produce the mtree files that makefs can =
then use to create images with the right ownership without needing root =
on the host, or to have the metadata live in the filesystem.
Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0D02B52A-662A-4A42-A239-A9A5D3ABA403>