Date: Wed, 7 Apr 2010 20:49:25 -0700 From: Garrett Cooper <yanefbsd@gmail.com> To: Tim Kientzle <kientzle@freebsd.org> Cc: arch@freebsd.org, portmgr@freebsd.org Subject: Re: [RFC] Remove pkg_add -C (chroot functionality) Message-ID: <v2g7d6fde3d1004072049mf8dfd7fcz800dca96f7d27123@mail.gmail.com> In-Reply-To: <4BBD3DCB.4030902@freebsd.org> References: <t2m7d6fde3d1004070216m94cfea44s86e70cf8ac9895d5@mail.gmail.com> <4BBD3DCB.4030902@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 wit= h >> 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. Thanks, -Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v2g7d6fde3d1004072049mf8dfd7fcz800dca96f7d27123>