Date: Wed, 7 Apr 2010 02:16:37 -0700 From: Garrett Cooper <yanefbsd@gmail.com> To: arch@freebsd.org Cc: portmgr@freebsd.org Subject: [RFC] Remove pkg_add -C (chroot functionality) Message-ID: <t2m7d6fde3d1004070216m94cfea44s86e70cf8ac9895d5@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Hi Arch folks,
I've talked with flz really briefly about this, and while he said
it was ok, I want to make sure that removing the functionality makes
logical sense.
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. Whilst fixing this seems trivial (apply a
chroot to only the top-level caller), it would require API changes, as
well as converting some of the vsystem (variadic system(3) lib-) calls
to fork(3) -> exec(3) to get things working properly with chroot(2),
and could in fact further add to the spaghetti mess that is
pkg_install(1) today.
The goal that several folks are undertaking to improve pkg_install
is to simplify it by pruning away unnecessary features (wherever
possible), and this functionality isn't actively used in any of the
mainstream tools (portmaster, portupgrade, sysinstall, etc). Does
anyone pragmatically oppose this change? If so, why?
Also, I'll be sure to run it through ports@ too so people get a
little bit of say in this (unless I receive an astounding no here),
but given that there was only one situation where this functioned for
me, I'd much rather have a complete functional solution in < 20 lines
of script that I can adjust to my needs than a broken (and pretty
useless) feature in pkg_add(1).
Thanks,
-Garrett
[1] bin/109334
Reasons for removing the feature:
1. Broken.
2. There's a large degree of environment setup required in order to
have a functional chroot / jail, that can't be resolved by pkg_add -C
.
3. The equivalent command is simple: chroot $DESTDIR pkg_add <...>
4. Certain pkg_install(8) operations can only be performed on a live
system (adding a user for instance, checking a font cache, etc).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?t2m7d6fde3d1004070216m94cfea44s86e70cf8ac9895d5>