[RFC] Remove pkg_add -C (chroot functionality)

[Garrett Cooper]

On Wed, Apr 7, 2010 at 7:22 PM, Tim Kientzle <kientzle at freebsd.org> wrote:
> Garrett Cooper wrote:
>>
>>    There's an outstanding bug to fix chroot(2)'ing functionality with
>> 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:
>  * update $ROOTDIR/var/db/pkg
>  * 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.  (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.  On 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).  On 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.

Thanks,
-Garrett