From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j4BA4hVF031569 for ; Wed, 11 May 2005 10:04:43 GMT Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by smtp.gentoo.org with esmtp (Exim 4.43) id 1DVo59-0004v9-VY for gentoo-dev@lists.gentoo.org; Wed, 11 May 2005 10:04:48 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DVnwx-0005le-Ae for gentoo-dev@gentoo.org; Wed, 11 May 2005 11:56:19 +0200 Received: from ip68-230-66-193.ph.ph.cox.net ([68.230.66.193]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 May 2005 11:56:19 +0200 Received: from 1i5t5.duncan by ip68-230-66-193.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 May 2005 11:56:19 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: Re: Re: New category proposal Date: Wed, 11 May 2005 03:03:14 -0700 Organization: Sometimes Message-ID: References: <20050508235004.GL6541@celeborn.wh-og.hs-niederrhein.de> <20050509001920.GC12085@ols-dell.gg3.net> <20050509170725.GC21777@kaf.zko.hp.com> <1115717301.25756.14.camel@nosferatu.lan> <20050510110404.GB5931@ols-dell.gg3.net> <20050511033055.GC16717@exodus.wit.org> <20050511042745.GA22277@ols-dell.gg3.net> <20050511050920.GC17034@exodus.wit.org> <20050511065023.GE17034@exodus.wit.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-66-193.ph.ph.cox.net User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Sender: news X-Archives-Salt: fa345a87-76b5-4b20-bb09-28b65249a1b6 X-Archives-Hash: 25602b313e6030d8be785080bcf63910 Brian Harring posted <20050511065023.GE17034@exodus.wit.org>, excerpted below, on Wed, 11 May 2005 01:50:23 -0500: > Umm. yes? > Cleanup of stuff in general is in the works, including (done when it's > done) binpkg handling being tweaked, which may or may not cover the > huge-ass block of requests above :) I see I didn't effectively convey what I wanted, then, if the description is a "huge-ass block of requests". =8^) Let's see if I can reword it a bit more effectively... What I had in mind (and tried to describe), was a /single/ (if large) /general/ feature, call it FEATURE=binpkg-name, to be combined with a second parameter enabled by that feature, BINPKG-NAME=. would then either be a) created as a subdir of the existing $PKGDIR, or b) appended to the name of the package in the existing dir, preferably creating a double-extension, as in bash-3.0-r11.gcc4.tbz2, if (as in my example, the reason I'd presently find this useful) BINPKG-NAME="gcc4". Thus, for this specific use, I'd either a) have a $PKGDIR/gcc4 subtree in addition to the normal $PKGDIR subtree (which would be equivalent to BINPKG-NAME=""), or b) have individual packages such as bash-3.0-r11.gcc4.tbz2, as well as possibly having the normal bash-3.0-r11.tbz2, with the feature or BINPKG-NAME var unset. However, as envisioned, the feature would be generalized enough to allow all sorts of other uses as well, perhaps for MULTILIB (MULTIAPP??) folks, a separate 32-bit and 64-bit copy of the same package, use of the same general $PKGDIR location with different archs due to the possible subtrees (or subnames), or for any other sort of testing or local use where creating a binpkg that doesn't overwrite a previous version might be useful. The key here is that the feature as implemented would be general enough to allow all sorts of local flexibility as to how it was used. So far, I've only discussed portage binpkg creation. Use of those additional binpkg subtrees/subnames could remain manual only, requiring the user/admin to shuffle the desired binpkg back into the default location, and still be quite useful. Alternatively, and probably when the second half of implementation is complete, portage would account for the feature, and if it was on read the var and draw from the appropriate subtree/subname (a or b options above) as configured. /IF/ that makes any more sense... Single feature, implemented as a toggle feature with a var pointer, thus generalizing the use. If the above were to be implemented, gcc-config could then possibly take advantage of it, appending to the local installation set BINPKG-NAME var for experimental versions of gcc. If the feature was set, it would then automatically create its own experimental binpkgs which wouldn't overwrite existing versions. If the feature was unset, setting BINPKG-NAME wouldn't have any effect. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list