[gentoo-dev] ebuild versioning schemes / cvs ebuilds: to the Portage/emerge managers

[gentoo-dev] ebuild versioning schemes / cvs ebuilds: to the Portage/emerge managers

[Dan Armak]

This is a query to the managers of Portage (drobbins etc.) about the ebuild
versioning schemes.

What I want is to implement CVS ebuilds, which will update a local code base 
via
cvs/cvsup/rsync/... and compile/install from that. This is useful with 
projects
like KDE, Ogg Vorbis and others that have more or less stable CVS code, and 
also
any projects in whose development the user participates. This raises two 
issues:

Issue 1
The smaller one: storage of the code between updates. This must be done since
the whole point of CVS is fast updates. We could for example tar/gzip the code
base and put it in distfiles under $P-cvs.tar.gz. The only objection to this 
is
speed. (It can take a long while to compress say 50 MB+).
Also, there is the question of optionally cleaning the code between updates. 
If
the user wants to build from cvs, every few days, something as large as KDE, 
it
would be very useful to keep the intermediary files. On the other hand this
would bloat disk usage/compression times.
Optimally the user should be able to control all this. A vision: the user 
would
have a separate code base which he could use to work on the project, commit to
CVS etc. But, it would be buildable via Portage to manage
depends/provides/versions better. After all it's one of Gentoo's goals that
every package built/installed on the system is there via Portage is possible.
I realize this is post-1.0 stuff, but it'd be nice to have some official
guidelines etc.

Issue 2
This is the large issue: ebuild versioning.
The current versioning scheme is inflexible IMHO. many packages have
non-standard version like LyX 1.1.6fix2 for example which can't be handled by
the existing scheme. And if we add cvs ebuilds, adding a _cvs version postfix
to the handler won't help, because you can't compare CVS versions with release
version numbers. The only way to do that would be to mark both cvs versions 
and
release versions with timestamps, and even then you could have several cvs
versions in one day (so they'd have the same timestamp).
CVS is _always_ newer than _any_ release version! (Unless it hasn't been
updated.)
The idea was raised of marking cvs versions as belonging to the period
between two adjacent releases. For example the cvs between kde 2.1.2 and
2.2_alpha1.
However this still has drawbacks. You can't compare different cvs revisions.
This is because whenever you rebuild a cvs ebuild (from current cvs 
presumably)
it's newer than whatever you previously had installed. And you can't code the
version into the ebuild file. Unless you tell cvs to get a specific tiestamped
revision. But you don't need that, you need the latest cvs. Which is always
newer than the last release version. Ugh.
I put these question on IRC and got no new ideas. Granted, there was only 1
other participant in the chat.
Therefore, it appears that something more radically new is needed for 
versioning
cvs ebuilds.

So - please reply and comment!

Dan Armak