From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on finch.gentoo.org X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=DMARC_NONE,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=4.0.0 Received: from tesla.newpaltz.edu (tesla.newpaltz.edu [137.140.1.102]) by chiba.3jane.net (Postfix) with ESMTP id 748752015D9C for ; Wed, 20 Feb 2002 04:09:04 -0600 (CST) Received: from res57-81.resnet.newpaltz.edu (res57-81.resnet.newpaltz.edu [137.140.57.81]) by tesla.newpaltz.edu (8.9.3/8.9.3) with ESMTP id FAA11484 for ; Wed, 20 Feb 2002 05:07:05 -0500 (EST) Subject: Re: [gentoo-dev] prefix overide portage From: "Bruce A. Locke" To: gentoo-dev@gentoo.org In-Reply-To: <20020220070237.GA3364@zad.att.ne.jp> References: <87r8ngd9uf.fsf@tea.thpoon.com> <20020220070237.GA3364@zad.att.ne.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 20 Feb 2002 05:07:48 -0500 Message-Id: <1014199668.5067.17.camel@kodiak.chronospace.org> Mime-Version: 1.0 Sender: gentoo-dev-admin@gentoo.org Errors-To: gentoo-dev-admin@gentoo.org X-BeenThere: gentoo-dev@gentoo.org X-Mailman-Version: 2.0.6 Precedence: bulk Reply-To: gentoo-dev@gentoo.org List-Help: List-Post: List-Subscribe: , List-Id: Gentoo Linux developer list List-Unsubscribe: , List-Archive: X-Archives-Salt: 6e88c604-2c51-4cbc-b45f-19ddf91d5bef X-Archives-Hash: 487c090fd529e7770a0a0ba985044477 On Wed, 2002-02-20 at 02:02, Matt Doughty wrote: > Portage packages: leaving the default to /usr is fine, but I would > really think that shouldn't become a dumping ground like it has > in so many other distros. I can understand those who don't care > can leave it in default dumping ground mode, and still allow > those of us who like a "cleaner" solution to have our way. Yes its a matter of personal preference. Personally I hated fbsd's use of /usr/local and the filesystem looked quite cluttered and unorganized (ditto goes for Solaris). But it is a matter of personal preference. > I personally would like to leave /bin,/sbin,/lib /usr/bin,/usr/lib, > and /usr/sbin alone after the initial bootstrap. I don't want > optional packages to intermingle in the same file space as those > that are needed for the system to function. The ability to create > a clean delineation is doing the right thing(TM) from my perspective. Again a preference. I don't share your view as there is no technical basis for the view in my opinion. There is no /usr/src in gentoo and no seperation between "core" and "optional". But there should be nothing to stop you from doing what you want :) > I think this really ammounts to good engineering, and if the goal is > to be more flexible than the ports/pkgsrc system this is needed > functionality. Agreed. > On a related note, I think it would be wise to clearly delineate > packages that are needed for basic booting system in some way. If > this functionality already exists, and I missed it please let me > know. Gentoo supports the concept of profiles. Much more powerful then a simply marking something as "core", etc :) See /usr/portage/profiles/default-1.0_rc6/packages and the portage source code for more information. > My main thought here is I want the ability to rebuild the > base system readily. Actually the more I think of it the better it > would be if one could say bootstrap a system to test directory first > (maybe /usr/local/base-test) and then assuming a possibly even chrooting > to test the new base simply reinstall the proper place or rerun the > bootstap without the overridden directory. You can (kinda) do that already though its not as elegant as having a relocatable prefix. You could grab our build tarball from the website, untar it into a directory, chroot it, and follow steps similar to those outlined in the install guide. If you want to play around with usermode linux, just toss the tarball on a loopback filesystem and go from there :) > One way or another the > ability to override the target for a package has many practical > applications. Once again, let me know what I can do to help with this. >>From my understanding we'd need some variables defined in /etc/make.conf or /etc/make.globals (with current behaviors as the default) and support in portage to override these variables on a per package basis from the comamnd line. Does portage already have this functionality in 1.8.9-pre*? After that it would be a matter of people interested in it updating their favorite ebuilds and developers with CVS access making sure all new ebuilds going into the tree follow the scheme. I feel bugzilla getting a tad busy in a couple weeks ;) -- Bruce A. Locke blocke@shivan.org