Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] splitting cvs spells

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: "Andraž \"ruskie\" Levstik" <ruskie AT mages.ath.cx>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] splitting cvs spells
  • Date: Sat, 7 Oct 2006 13:54:42 +0200

Juuso Alasuutari wrote :

> gpg: Signature made sob 07 okt 2006 12:22:16 CEST using DSA key ID B00895FD
> gpg: Good signature from "Juuso Alasuutari (iuso) <iuso AT sourcemage.org>"
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg: There is no indication that the signature belongs to the
> owner.
> Primary key fingerprint: 41C2 5BE1 934A 2C27 8FE7 8BEA 43F4 CD41 B008 95FD
>
>
> Hi again. I've put together a more detailed collection of arguments to
> demonstrate my point. I've tried to take into account all that's been said
> so
> far, please tell me if I've missed anything.
>
> Unjoy! ;)
>
>
> Arguments against my opinion I think are valid:
>
> * Grimoire size.
> - More spells equals a bigger grimoire. Can't get around this one. (On
> the
> other hand, having a cvs spell for each program shouldn't be the norm.
> Also,
> shrinking the grimoire can and should be achieved by other means, too, like
> setting up the deprecated grimoire and doing general pruning.)
>
>
> Arguments against my opinion I disagree with:
>
> * "Only split if non-compatible, otherwise put cvs in main spell."
> - The rationale for dual-versioned spells goes that cvs should be
> separated
> from stable only if it's not compatible as a dependency, but this is a line
> drawn in water. Cvs is volatile, and the devel version may at any time
> change
> its behavior enough to cause compatibility issues. A spell is a static
> entity
> when compared against a cvs repository, and unless it's declared cvs in its
> entirety, it can't rely on a repository to not change its contents.
>
>

Let's NOT focus on ONLY $SCM spells. Here's a few spells that have a
choice between more versions:

xmms2 - I think this is quite advanced
fvwm - 3 versions, stable, devel AND cvs
zsh - 3 versions, stable, devel AND cvs


> My arguments so far:
>
> * Separated stable and cvs spells are easier to parse.
> - It's much easier to parse e.g. VERSION and SOURCE_URL when they aren't
> nested inside conditionals. Not long ago we had to change the SOURCE_URLs
> in
> all sourceforge-hosted cvs spells, which would've been _much_ easier to
> script had all cvs spells been separate entities. This issue is also
> visible
> in how 'gaze versions' doesn't really work properly with dual-versioned
> spells.
>

It was never meant to work with them...
I belive it was agreed long ago that we won't be providing any versioned
spells unless where necessary and there as a separate spell.

Examples:
automake 1.9 - automake
automake 1.8 - automake1.8
automake 1.7 - automake1.7
sqlite 3.x - sqlite
sqlite 2.x - sqlite2

> * Separating cvs from stable makes spells less volatile.
> - First you have a spell with both stable and cvs. Then something happens
> -
> the cvs's options change dramatically, or some other spell specifically
> requires the cvs version - and you need to split them. Then some time
> passes,
> and eventually the stable version is updated so that it again shares its
> features with the cvs code. Now you're supposed to merge them again, right?
> Ad infinitum... You could've just had 'em separate from start.
>
> * Dual-versioned spells are more work.
> - A dual-versioned spell effectively forces the updater of a stable
> version
> to spend more energy and time, because leaving the cvs options untested for
> new/changed stuff when updating the stable portion isn't good practice (or
> at
> least not very polite). We should really focus on getting stable stuff to
> work before anything else, and this shouldn't get slowed down because of
> dual-versioned spells.

I'll join the up two points since they aren't separate...

It's not more work... it's LESS work.
Example:
xmms2 spell

Imagine I'd need a separate spell for each of those trees etc etc...
It means N*times DETAILS file N*times HISTORY file N*times DEPENDS file
etc etc etc...
Not only in size.. also in that I'd need to be setting options in each
separately etc... It would be a RUN away beast.

Imagine we would have the linux spell like that.

And IF $SCM changes drasticaly hey it's from a volatile source it's at
your own risk... Personaly I'd like to see in ALL the spells that use
volatile sources a HUGE disclaimer in the form of the one in dri spell's
PREPARE file.

Example:
echo "This spell is a development version, bleeding edge stuff..." &&
echo "If you feel secure at casting cvs or other cvs-like sources" &&
echo "then answer yes to the following question to cast the spell" &&
echo " !!!***THIS SPELL MAY DAMAGE YOUR INSTALLATION***!!! " &&
query "Do you wish to cast this spell after you have been informed of
the danger" "n" || return 1 &&


>
> * A spell should simply work.
> - Deriving from the previous point: A spell is expected to work, period.
> We
> can't say: "It'll work unless you press that button there, then we can't
> really say" - not even if the button says "cvs". But on the other hand,
> because we _do_ want to provide cvs versions, and because we _can't_ vouch
> for cvs's stability, we should always separate cvs from stable spells. That
> way the normal spells are stable all the way, and the cvs spells are
> semantically declared unstable by their very naming.
>
>

And they do simply work STABLE versions which we acctually support and
try to fix. Development/$SCM versions we don't really support other than
to make it compatible when needed i.e. gcc 3.x v gcc 4.x.
(Atleast I belive this is the case)

IF a spell needs a specific development version then it's added as a
separate spell and supported as a normal version else it's just a volatile
option that we offer to our users if they want it.

"We DON'T prohibit our users from breaking their system. We LET them do
what THEY think is best."



--
Andraž "ruskie" Levstik
Source Mage GNU/Linux Games grimoire guru
Geek/Hacker/Tinker

Hacker FAQ: http://www.plethora.net/%7eseebs/faqs/hacker.html
Be sure brain is in gear before engaging mouth.

Key id = A7A9E461
Key fingerprint = 757E C16B F5B7 DC27 B003 CCED CF95 3A77 A7A9 E461





Archive powered by MHonArc 2.6.24.

Top of Page