From owner-freebsd-arch Mon Jul 8 7:31:20 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADE4B37B400; Mon, 8 Jul 2002 07:31:17 -0700 (PDT) Received: from thuvia.demon.co.uk (thuvia.demon.co.uk [193.237.34.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1948F43E54; Mon, 8 Jul 2002 07:31:12 -0700 (PDT) (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (dotar.thuvia.org [10.0.0.4]) by phaidor.thuvia.org (8.11.6/8.11.6) with ESMTP id g68EUmb10797; Mon, 8 Jul 2002 15:30:48 +0100 (BST) (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (localhost [IPv6:::1]) by dotar.thuvia.org (8.12.3/8.12.3) with ESMTP id g68EUlKC062948; Mon, 8 Jul 2002 15:30:47 +0100 (BST) (envelope-from mark@dotar.thuvia.org) Received: (from mark@localhost) by dotar.thuvia.org (8.12.3/8.12.3/Submit) id g68EUgoZ062947; Mon, 8 Jul 2002 15:30:42 +0100 (BST) Date: Mon, 8 Jul 2002 15:30:42 +0100 (BST) From: Mark Valentine Message-Id: <200207081430.g68EUgoZ062947@dotar.thuvia.org> In-Reply-To: Garance A Drosihn's message of Jul 8, 2:04am X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: drosih@rpi.edu (Garance A Drosihn), Wes Peters , Dan Moschuk Subject: Re: Package system flaws? Cc: arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > From: drosih@rpi.edu (Garance A Drosihn) > Date: Mon 8 Jul, 2002 > Subject: Re: Package system flaws? > I do find the ports collection one of the most useful things in > the freebsd community, but the more comfortable you get with > depending on it, the more you see little cracks where various > problems crop up -- over and over again. Indeed the system is very useful already. But here are my main gripes anyway... 1. Packages install to /usr/local by default; however, they do not (and cannot) follow my long-standing (since 4.2BSD) cross-platform administrative policies for /usr/local. In fact, just attempting a package install on those systems generally screws up the permissions on /usr/local fatally. The next generation system should install to /usr/pkg or /opt or whatever. (Policy differences here: my /usr/local is generally administered by group "staff", not user "root"; I put in a bit of effort to generally _not_ require the co-existence of multiple versions of a package - a lot of the ports patches are there to accomplish just this, renaming libraries and data directories - I don't want it). 2. I'd like to see improved support for building/installing packages as non-root. Installing as root should only be necessary if local policy requires it, or if there are set[ug]id components to install (or similar permission requirements). Even in the latter case it would be nice if the install created a simple script to run as root to fix up the permissions. I especially don't like having to build ports as root (I consider bsd.port.mk unauditable, and I know a thing or two about make(1)). 3. There's no way to have pkg_add -r use a local package cache so that only the first install needs to fetch the package _and its dependencies_ over the Internet (see Cygwin's setup.exe for an example of how this can be done reasonably well). I went to add this feature and my stumbling block was that pkg_add doesn't know the versioned name of the package archive to store (but only for the primary package, the dependencies are fine). That's to say that "pkg_add -r XFree86" should fetch and store (if necessary) "XFree86-4.2.0_1,1.tgz" and its dependencies; alternatively, "pkg_add -r XFree86-4.2.0_1,1.tgz" should do the right thing. Currently, to install a package on multiple systems, I have to jump through hoops to get the package and its dependencies into my local package area. > Separate from that, one thing I think we need is some mechanism > which makes certain that the generated package-list for a port > is exactly correct. I like your idea for creating packages from a chroot'd area, though I'd probably prefer this to be an optional testing feature than the default method (but yes, nobody would use it then...). Cheers, Mark. -- Mark Valentine, Thuvia Labs "Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses "We're kind of stupid that way." *munch* *munch* and endorses FreeBSD -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message