Date: Sat, 10 Apr 2010 00:34:53 -0700 From: Garrett Cooper <yanefbsd@gmail.com> To: Tim Kientzle <kientzle@freebsd.org> Cc: arch@freebsd.org, freebsd-ports <freebsd-ports@freebsd.org>, portmgr@freebsd.org Subject: Re: [RFC] Remove pkg_add -C (chroot functionality) Message-ID: <r2u7d6fde3d1004100034me51d782pec1d4ef163e3262a@mail.gmail.com> In-Reply-To: <v2g7d6fde3d1004072049mf8dfd7fcz800dca96f7d27123@mail.gmail.com> References: <t2m7d6fde3d1004070216m94cfea44s86e70cf8ac9895d5@mail.gmail.com> <4BBD3DCB.4030902@freebsd.org> <v2g7d6fde3d1004072049mf8dfd7fcz800dca96f7d27123@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 7, 2010 at 8:49 PM, Garrett Cooper <yanefbsd@gmail.com> wrote:
> On Wed, Apr 7, 2010 at 7:22 PM, Tim Kientzle <kientzle@freebsd.org> wrote=
:
>> Garrett Cooper wrote:
>>>
>>> =A0 =A0There's an outstanding bug to fix chroot(2)'ing functionality wi=
th
>>> pkg_add(1) [1]. Anyone that has tried this functionality knows that
>>> it's currently crippled
>>
>> If it's currently broken, it's better to
>> simply remove it.
>>
>> I'm not sure I understand why anyone wants
>> pkg_add to call chroot(2) at the top, though.
>> As you pointed out, "chroot pkg_add" exists
>> already.
>>
>> The feature we need should:
>> =A0* update $ROOTDIR/var/db/pkg
>> =A0* Add $ROOTDIR as a prefix to all installed file locations
>> This would allow pkg_add when running outside of
>> a chroot to install packages into a chrooted
>> system, which is what you can't easily do with
>> "chroot pkg_add".
>
> As discussed in #bsdports with flz, it's much more complicated because
> in the future we'll most likely have mainstream support for
> cross-building where this isn't possible, i.e. build arm on i386 --
> the point is that there are some steps that must be run on the target
> system or chroot, and this quite frankly isn't possible without being
> able to install directly on the target. Regardless, cross-building
> right now requires that one define the proper environment, and again
> that can't be delivered with pkg_add without introducing unneeded
> complexity. Point being, if someone wants to chroot, and they
> understand the complete exercise, or if we have documentation provided
> which demonstrates how to do so, people will use it, and potentially
> grow upon it in a positive way. Right now this is just a vestige of
> brokenness in pkg_install that should go IMO.
>
>> Of course, this isn't particularly easy to do when
>> forking tar(1), so the libarchive integration
>> might be a necessary prerequisite. =A0(Command-line
>> tar doesn't support re-rooting absolute paths.
>> There is a --chroot option to tar, but it's
>> currently broken in some rather complex ways.
>> As I'm composing this message, I'm starting to
>> wonder if it also should not use chroot(2).
>> Hmmm....)
>>
>> The hard part is @exec/@unexec. =A0On the one
>> hand, you don't necessarily want to require
>> the install dependencies of a package to be
>> installed in the chroot, which argues against
>> running those under chroot(2). =A0On the other hand,
>> a lot of the commands used within @exec/@unexec
>> manipulate common system databases (e.g., ldconfig),
>> which argues that those commands should be run
>> under chroot(2).
>
> Bingo -- that is the cruxt of the problem with doing chroot(2) with
> pkg_add. From a support perspective it's a nightmare because when
> something does go south, you're up a crik without a paddle trying to
> figure out what the heck is going on... it's better for us that
> someone is running with a stable, pre-defined system than try and
> force them to use a home grown / unknown method built around a shaky
> base.
It's been two days without a lot of commentary. Expanding to a
larger audience...
Thanks,
-Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?r2u7d6fde3d1004100034me51d782pec1d4ef163e3262a>