| 1 |
Brian Harring posted <20050511065023.GE17034@××××××××××.org>, excerpted |
| 2 |
below, on Wed, 11 May 2005 01:50:23 -0500: |
| 3 |
|
| 4 |
> Umm. yes? |
| 5 |
> Cleanup of stuff in general is in the works, including (done when it's |
| 6 |
> done) binpkg handling being tweaked, which may or may not cover the |
| 7 |
> huge-ass block of requests above :) |
| 8 |
|
| 9 |
I see I didn't effectively convey what I wanted, then, if the description |
| 10 |
is a "huge-ass block of requests". =8^) Let's see if I can reword it a |
| 11 |
bit more effectively... |
| 12 |
|
| 13 |
What I had in mind (and tried to describe), was a /single/ (if large) |
| 14 |
/general/ feature, call it FEATURE=binpkg-name, to be combined with a |
| 15 |
second parameter enabled by that feature, BINPKG-NAME=<whatever>. |
| 16 |
<whatever> would then either be a) created as a subdir of the existing |
| 17 |
$PKGDIR, or b) appended to the name of the package in the existing dir, |
| 18 |
preferably creating a double-extension, as in bash-3.0-r11.gcc4.tbz2, if |
| 19 |
(as in my example, the reason I'd presently find this useful) |
| 20 |
BINPKG-NAME="gcc4". |
| 21 |
|
| 22 |
Thus, for this specific use, I'd either a) have a $PKGDIR/gcc4 subtree in |
| 23 |
addition to the normal $PKGDIR subtree (which would be equivalent to |
| 24 |
BINPKG-NAME=""), or b) have individual packages such as |
| 25 |
bash-3.0-r11.gcc4.tbz2, as well as possibly having the normal |
| 26 |
bash-3.0-r11.tbz2, with the feature or BINPKG-NAME var unset. |
| 27 |
|
| 28 |
However, as envisioned, the feature would be generalized enough to allow |
| 29 |
all sorts of other uses as well, perhaps for MULTILIB (MULTIAPP??) folks, |
| 30 |
a separate 32-bit and 64-bit copy of the same package, use of the same |
| 31 |
general $PKGDIR location with different archs due to the possible subtrees |
| 32 |
(or subnames), or for any other sort of testing or local use where |
| 33 |
creating a binpkg that doesn't overwrite a previous version might be |
| 34 |
useful. The key here is that the feature as implemented would be general |
| 35 |
enough to allow all sorts of local flexibility as to how it was used. |
| 36 |
|
| 37 |
So far, I've only discussed portage binpkg creation. Use of those |
| 38 |
additional binpkg subtrees/subnames could remain manual only, requiring |
| 39 |
the user/admin to shuffle the desired binpkg back into the default |
| 40 |
location, and still be quite useful. Alternatively, and probably when |
| 41 |
the second half of implementation is complete, portage would account for |
| 42 |
the feature, and if it was on read the var and draw from the appropriate |
| 43 |
subtree/subname (a or b options above) as configured. |
| 44 |
|
| 45 |
/IF/ that makes any more sense... Single feature, implemented as a toggle |
| 46 |
feature with a var pointer, thus generalizing the use. |
| 47 |
|
| 48 |
If the above were to be implemented, gcc-config could then possibly take |
| 49 |
advantage of it, appending to the local installation set BINPKG-NAME var |
| 50 |
for experimental versions of gcc. If the feature was set, it would then |
| 51 |
automatically create its own experimental binpkgs which wouldn't overwrite |
| 52 |
existing versions. If the feature was unset, setting BINPKG-NAME |
| 53 |
wouldn't have any effect. |
| 54 |
|
| 55 |
-- |
| 56 |
Duncan - List replies preferred. No HTML msgs. |
| 57 |
"Every nonfree program has a lord, a master -- |
| 58 |
and if you use the program, he is your master." Richard Stallman in |
| 59 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
| 60 |
|
| 61 |
|
| 62 |
-- |
| 63 |
gentoo-dev@g.o mailing list |
Archives