[gentoo-dev] Dan: about your version question

[gentoo-dev] Dan: about your version question

[DDavies]

Hi, Dan

Well Ive been around here quite a long time, and I can fill you in on
a couple details.

FIrst of all, Daniel has noted that he plans to re-implement the download
system.  I have personally made the case here in the past (we're talking
like 4 months ago now) for lukemftp to be incorporated into the
download system.  The portage fetch subsystem totally needs
rethinking, and Im sure there are many issues Daniel is working on to
improve it.

One of these is the broken download, corrupt download thing.  This
shouldnt be hard to fix since resuming file transfers is easy to do, and
well supported by the various fetch programs out there.  Another thing
is the fact that SRC_URI needs to have USE dependency support added,
so files not needed for building arent downloaded.

Then theres the issue about perhaps extending .ebuild scripts to possibly
have a src_fetch() function.  In this way, you could write CVS or CVSup
commands to get source, and package it up or whatever you want.  Then
developers could get the benefit of being able to have CVS source trees
merged into their filesystem with all the nice benefits of portage.. like the
MD5 package database, the config file protection and everything else.

Of course my personal preference would be to extend SRC_URI to handle
cvs:// and maybe cvsup:// URL types!  Now that would be cool.  Come up
with a simple syntax for such a thing..  wow then portage would be the coolest
thing for linux development since gcc.  Of course Im just the sucker to volunteer
help come up with such a thing.  The need for this type of thing is pretty clear
in my opinion, I was just waiting untill somebody else spoke up to spark
interest.  Now Im not alone. heheh.

What other ideas are out there for improving the download subsystem?  Is
the wget.fetch, lukemftp.fetch thing still being thought out?

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

[Dan Armak]

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.)

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?

Dan

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

[Daniel Robbins]

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.  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?

Best Regards,

-- 
Daniel Robbins					<drobbins@gentoo.org>
President/CEO					http://www.gentoo.org 
Gentoo Technologies, Inc.			

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

[Dan Armak]

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