| 1 |
This is a query to the managers of Portage (drobbins etc.) about the ebuild |
| 2 |
versioning schemes. |
| 3 |
|
| 4 |
What I want is to implement CVS ebuilds, which will update a local code base |
| 5 |
via |
| 6 |
cvs/cvsup/rsync/... and compile/install from that. This is useful with |
| 7 |
projects |
| 8 |
like KDE, Ogg Vorbis and others that have more or less stable CVS code, and |
| 9 |
also |
| 10 |
any projects in whose development the user participates. This raises two |
| 11 |
issues: |
| 12 |
|
| 13 |
Issue 1 |
| 14 |
The smaller one: storage of the code between updates. This must be done since |
| 15 |
the whole point of CVS is fast updates. We could for example tar/gzip the code |
| 16 |
base and put it in distfiles under $P-cvs.tar.gz. The only objection to this |
| 17 |
is |
| 18 |
speed. (It can take a long while to compress say 50 MB+). |
| 19 |
Also, there is the question of optionally cleaning the code between updates. |
| 20 |
If |
| 21 |
the user wants to build from cvs, every few days, something as large as KDE, |
| 22 |
it |
| 23 |
would be very useful to keep the intermediary files. On the other hand this |
| 24 |
would bloat disk usage/compression times. |
| 25 |
Optimally the user should be able to control all this. A vision: the user |
| 26 |
would |
| 27 |
have a separate code base which he could use to work on the project, commit to |
| 28 |
CVS etc. But, it would be buildable via Portage to manage |
| 29 |
depends/provides/versions better. After all it's one of Gentoo's goals that |
| 30 |
every package built/installed on the system is there via Portage is possible. |
| 31 |
I realize this is post-1.0 stuff, but it'd be nice to have some official |
| 32 |
guidelines etc. |
| 33 |
|
| 34 |
Issue 2 |
| 35 |
This is the large issue: ebuild versioning. |
| 36 |
The current versioning scheme is inflexible IMHO. many packages have |
| 37 |
non-standard version like LyX 1.1.6fix2 for example which can't be handled by |
| 38 |
the existing scheme. And if we add cvs ebuilds, adding a _cvs version postfix |
| 39 |
to the handler won't help, because you can't compare CVS versions with release |
| 40 |
version numbers. The only way to do that would be to mark both cvs versions |
| 41 |
and |
| 42 |
release versions with timestamps, and even then you could have several cvs |
| 43 |
versions in one day (so they'd have the same timestamp). |
| 44 |
CVS is _always_ newer than _any_ release version! (Unless it hasn't been |
| 45 |
updated.) |
| 46 |
The idea was raised of marking cvs versions as belonging to the period |
| 47 |
between two adjacent releases. For example the cvs between kde 2.1.2 and |
| 48 |
2.2_alpha1. |
| 49 |
However this still has drawbacks. You can't compare different cvs revisions. |
| 50 |
This is because whenever you rebuild a cvs ebuild (from current cvs |
| 51 |
presumably) |
| 52 |
it's newer than whatever you previously had installed. And you can't code the |
| 53 |
version into the ebuild file. Unless you tell cvs to get a specific tiestamped |
| 54 |
revision. But you don't need that, you need the latest cvs. Which is always |
| 55 |
newer than the last release version. Ugh. |
| 56 |
I put these question on IRC and got no new ideas. Granted, there was only 1 |
| 57 |
other participant in the chat. |
| 58 |
Therefore, it appears that something more radically new is needed for |
| 59 |
versioning |
| 60 |
cvs ebuilds. |
| 61 |
|
| 62 |
So - please reply and comment! |
| 63 |
|
| 64 |
Dan Armak |
Archives