sm-discuss AT lists.ibiblio.org
Subject: Public SourceMage Discussion List
List archive
RE: [SM-Discuss] How to handle multi-version spells
- From: "David Michael Leo Brown Jr." <dmlb2000 AT excite.com>
- To: sm-discuss AT lists.ibiblio.org
- Subject: RE: [SM-Discuss] How to handle multi-version spells
- Date: Sat, 7 May 2005 21:59:48 -0400 (EDT)
>Hi everyone.
>
>We have quite some spells that support multiple versions based on a user
>choice. Right now basically all of them behave differently. I'd like to
>have a unified behaviour so the user always knows what to expect.
>
>First of all: If any other spell depends on a specific version of spell
>A then spell A _must not_ allow other versions. This means that the
>current apr/apr-util spells are broken as the apache2 spell requires the
>0.9.x versions of them. In such cases the different versions should be
>provided by seperate spells, see ffmpeg/ffmpeg-cvs for another example
>where this is required.
>
>Now for the actual versioned spell. The essential differences between
>the spells we currently have:
>- some spells default to stable version, some to cvs version
>- some spells set VERSION=$(date +%Y%m%d), other set VERSION=HEAD, i.e.
> some auto update everytime you run sorcery queue, others don't
>
>What I'd like to see:
>- spell asks which version to use, always defaulting to the stable
> version
>- spell asks if it should automatically update everytime sorcery
> queue/system-update is run (only for cvs/svn/... versions)
>All questions asked in PREPARE, dependency on the vcs added depending on
>the choice.
>
>If the spell is not set to automatically update, VERSION should be set
>to a constant string (e.g. HEAD, TRUNK). If the spell is set to
>automatically update VERSION should be set to $(date +%Y%m%d). This will
>lead to a new cache tarball every time the spell is updated which is
>intentional. If an automatic update broke something, the user can dispel
>-d to a previous version.
>
>If people agree with this I'll add it to the guru handbook and every
>mult-version spell not working according to this method will be
>considered a bug.
>
>Questions? Suggestions? Flames?
>
Well as for apr/apr-util Sergey and I talked about that a little we were going
to split it up into two spells; apr0 which apache2 would depend on and apr
which httpd-dev would depend on. We both agreed (iirc) that this would be the
best course of action to take with the apr/apr-util spells because the 0.9.X
versions aren't the active branch of apr/apr-util.
Other than that I think this is a fine idea, I like seting the date to
whatever
today is especially with ever changing constantly active cvs projects (ie
anjuta) and sometimes it's nice, on the slower changing cvs projects to just
get todays snapshot and be done with it...
- David Brown
_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
-
Re: [SM-Discuss] How to handle multi-version spells
, (continued)
- Re: [SM-Discuss] How to handle multi-version spells, Sergey A. Lipnevich, 05/12/2005
-
Re: [SM-Discuss] How to handle multi-version spells,
Eric Sandall, 05/12/2005
- Re: [SM-Discuss] How to handle multi-version spells, Sergey A. Lipnevich, 05/12/2005
- Re: [SM-Discuss] How to handle multi-version spells, Eric Sandall, 05/12/2005
- Re: [SM-Discuss] How to handle multi-version spells, Sergey A. Lipnevich, 05/12/2005
- Re: [SM-Discuss] How to handle multi-version spells, Eric Sandall, 05/12/2005
-
Re: [SM-Discuss] How to handle multi-version spells,
Arwed von Merkatz, 05/17/2005
- Re: [SM-Discuss] How to handle multi-version spells, Andrew, 05/17/2005
-
Re: [SM-Discuss] How to handle multi-version spells,
Arwed von Merkatz, 05/08/2005
-
Re: [SM-Discuss] How to handle multi-version spells,
Sergey A. Lipnevich, 05/11/2005
- Re: [SM-Discuss] How to handle multi-version spells, Arwed von Merkatz, 05/12/2005
-
Re: [SM-Discuss] How to handle multi-version spells,
Sergey A. Lipnevich, 05/11/2005
- Re: [SM-Discuss] How to handle multi-version spells, Sergey A. Lipnevich, 05/11/2005
Archive powered by MHonArc 2.6.24.