Remove pkg_add -C (chroot functionality)
in [Ports]
|
Prev: Now OK (Re: cvs commit: ports/graphics/ocaml-images Makefile)
Next: x11/nvidia-driver: VDPAU headers in /usr/local/include/vdpau now
From: Garrett Cooper on 10 Apr 2010 03:34 On Wed, Apr 7, 2010 at 8:49 PM, Garrett Cooper <yanefbsd(a)gmail.com> wrote: > On Wed, Apr 7, 2010 at 7:22 PM, Tim Kientzle <kientzle(a)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. It's been two days without a lot of commentary. Expanding to a larger audience... Thanks, -Garrett _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org" |