[gentoo-dev] Re: Re: Re: New category proposal

[Duncan <1i5t5.duncan@cox.net>]

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=<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