Re: [Chicken-hackers] Egg filename versioning

[Leonardo Valeri Manera]

On 07 Feb 2008 15:49:56 -0200, Mario Domenech Goulart
<address@hidden> wrote:
> Hi Leonardo,
>
> On Thu, 7 Feb 2008 16:42:33 +0100 "Leonardo Valeri Manera" <address@hidden> 
> wrote:
>
> > To make it all actually work though, we need to be able to
> > differentiate the different egg versions by filename ... that's not to
> > say it has to be the actual *VERSION* - if that's too complex to do,
> > the release date will do just fine:
> >
> > The version used in the ebuild's version field does not have to be the
> > same as the one in the file (egg in this case) to be downloaded.
> >
> > Obviously, it helps for "packager sanity" reasons, and makes it easier
> > to make upgrades - since the version part of the ebuild's (the script
> > that tells the package manager how to build a package) name is
> > available as $PV inside the ebuild's environment, often its enough to
> > change the name of the ebuild for it work with new package releases.
> >
> > In any case, something like:
> >
> > <egg-name>-<major chicken version>-<egg version or date>-egg
> >
> > eg.
> >
> > args-3-1.2.egg
> > or
> > args-3-20070620.egg
> >
> > will do for us.
>
> I'm trying to think of a way to implement what you need.  Here are
> some doubts:
>
> 1. Is it ok if the server gives a eggname.egg response to a
>    eggname-version.egg request?

No, then the package manager will have no way of knowing to download
another file on version bumps, and will just fail at installation when
checksumming the file.

> 2. I suppose we'd have an ebuild file for each version of a given egg.
>    Eggs development is pretty dynamic, we have new versions every day.
>    Would it be feasible to keep ebuilds in synch?  I think it's worth
>    mentioning that the eggs repository doesn't keep old versions in it
>    (only the latest).

Well, we were gonna start by providing ebuilds for the more "widely
used" ones, perhaps even some in packs (multiple eggs per ebuild) and
go from there.

The main reason we'd like to do this is so users have their eggs
autoupgraded with the rest of their packages.

Providing upgraded ebuilds will be easy: once we have the shared
functions for egg installation done, it will be as easy as making a
copy of say, blah-20070203.ebuild, renaming it to
blah-20070205.ebuild, and killing the old version.

The ebuild, via the eclass functions, will detect the major chicken
number the user is using and construct the correct filename for it.
Having all the compilation taken care of by chicken-setup makes this
even easier than normal - no checking if they changed the build
system, no checking if uses its own version of libtool, etc.

I've talked about this on and off with the big kahooas oh gentoo
scheme, but all our schemes (heh) so far have been pure theory because
we have had no way to make the package manager check if it has the
source file for a particular egg version just by looking at its
available source file list.