Brian Harring posted <[EMAIL PROTECTED]>, 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=<whatever>. <whatever> 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
