Public SourceMage Discussion List

["Andraž \"ruskie\" Levstik" <ruskie AT mages.ath.cx>]

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