Re: [gentoo-dev] Dan: about your version question

[Dan Armak <ermak@netvision.net.il>]

On Monday 09 July 2001 18:38, you wrote:
> On Mon, Jul 09, 2001 at 10:23:41AM +0300, Dan Armak wrote:
> > Hi,
> >
> > Thanks for the reply. My most important question is still unanswered
> > however: the one about versioning.
> > To summarize my previous post: CVS-derived packages can't be compared,
> > version-wise, with 'release' versions. A CVS package installed _now_ is
> > always the latest version, since it comes straight from CVS. But, a CVS
> > package installed any number of days ago may or may not be new enough.
> > So, we can't know whether or not dependencies are being satisfied.
> > (Unless we put a timestamp on all release versions added to Portage.)
>
> You're right; that's one of the main problems I see in integrating CVS into
> Portage.  There's just no way to get a good date for version comparision,
> at least if we rely completely on the CVS server.  One option is for the
> user to provide a specific "lead version", like 2.1.  Then the snapshot
> versions can be labelled 2.1_cvs20010709 and we can do some form of version
> comparison.  In thinking about this whole CVS thing, I think it may be best
> if we simply add the ability to automate the creation a .tar.bz2 snapshot
> of the CVS archive, properly labelled.  Then, it can be uploaded to ibiblio
> and installed the normal way.  However, as long as we use some kind of
> "lead version" technique, I should be able to add proper version
> comparisons for cvs stuff, and thus solve the biggest problem. 
> 2.1_cvs20010709 could be compared against 2.1, 2.1_pre, 2.1_rc3, 2.1.1,
> etc.  Because it's from CVS, I can have Portage assume that any 2.1 CVS
> release is newer than a 2.1 normal release (or even a p release).
>
> > A better idea I just had: if Portage can be _really_ integrated with cvs
> > management, we can fetch the _release_ version from CVS also! So, some
> > packages would go into "cvs mode", and would fetch either the specified
> > release version, or the latest release version, or the current version -
> > depending on the user's global/specific preferences. And then we could
> > query the CVS server for dates of release versions!
> >
> > What do you think?
>
> Well, I'm not sure how to do that.  If you can provide some examples of
> bash commands that'll do that, maybe we can integrate it into Portage. 

Well I can't give you the CVS commands from memory since I generally use 
CVSup when possible. But CVS stands for Concurrent Versioning System. 
Concurent, not Current. So you can get any version from it - either by date, 
or by release version number (the tag). All you need is to provide cvs with 
the right parameters.

> Also, we need to have a reason to use a release version from CVS if there's
> a release .tar.gz file as well.  Is the theory that the CVS release version
> will have the latest updates/bug fixes applied?

The reason is, that if you get the files from CVS you automatically get the 
release's date and time as well. So there's no problem in comparing versions: 
we can substitute release date for release version in this case.

So, we can have 'regular' packages - the way they are now. And we can have 
alternative 'cvs' packages - which will get their sources from cvs, cvsup, 
rsync, whatever. This can be done right now - bypassing the built-in fetching 
function of emerge and running cvs. Or, with some slight modifications to 
emerge (the long-rumoured fetch_uri ebuild implementation), we can make cvs 
just an alternative source for downloads for the release versions, and the 
only source for the current cvs version. Remember that ibiblio.org can't be a 
cvs mirror. Probably the KDE CVS database alone takes up a few GBs - it goes 
all the way back to KDE 0.x :-)

Well, as I said before, some (or all) of this may be post-1.0 stuff - but we 
should make any planning decisions now if possible.


Dan Armak

Dan