| 1 |
On Tue, 29 Apr 2003 14:21:40 -0400 |
| 2 |
Robert Thomas <rwt@×××××××××.edu> wrote: |
| 3 |
|
| 4 |
> Instead of having a separate package for a cvs version of a package, |
| 5 |
> why not consider the cvs version to be the latest version of a |
| 6 |
> package, but always marked unstable? |
| 7 |
|
| 8 |
They can't be done as ~arch as if I understand it this is testing and |
| 9 |
things should be likely to work but CVS builds stand a reasonable chance |
| 10 |
of failing due to upstream changes. |
| 11 |
|
| 12 |
> Since the cvs version of a |
| 13 |
> package usually overwrites the existing version, the old version |
| 14 |
> should be automagically unmerged. For example, in the case of gaim and |
| 15 |
> gaim-cvs, if the cvs version of gaim is installed, the stable version |
| 16 |
> should be unmerged as if it was an old version of the package. Perhaps |
| 17 |
> there is another way to manage this. |
| 18 |
> In the case of binary packages (like openoffice-bin), they should also |
| 19 |
> be considered to be the same package, but still kept separate in some |
| 20 |
> way. Perhaps another USE flag? |
| 21 |
> # USE="bin" emerge openoffice |
| 22 |
> |
| 23 |
> Or maybe cvs could be a new keyword: |
| 24 |
> # ACCEPT_KEYWORDS="cvs" emerge gaim |
| 25 |
> |
| 26 |
> Ok, I really am talking out of the wrong orifice here, and I know that |
| 27 |
> these ideas are probably a misuse of USE flags and KEYWORDS. I would |
| 28 |
> just like to know if something like this could work (not necessarily |
| 29 |
> the way I've described it, perhaps a different extention to the |
| 30 |
> version calculating routine altogether), or if there is a reason these |
| 31 |
> packages are managed the way they are (by "these" I mean all packages |
| 32 |
> ending in "-bin" or "-cvs"). |
| 33 |
|
| 34 |
Well, the ebuild has to be significantly different for a binary version |
| 35 |
to a source version, so trying to mix them would probably be a |
| 36 |
maintenance problem. |
| 37 |
|
| 38 |
Also the binary version might be ready to go stable |
| 39 |
before the source version, since it effectively only has to deal with |
| 40 |
*one* set of flags. |
| 41 |
-- |
| 42 |
Mark Gordon |
| 43 |
Paid to be a Geek & a Senior Software Developer |
| 44 |
Currently looking for a new job commutable from Slough, Berks, U.K. |
| 45 |
Although my email address says spamtrap, it is real and I read it. |
| 46 |
|
| 47 |
-- |
| 48 |
gentoo-dev@g.o mailing list |
Archives