Bugzilla – Bug 8333
support for multiple versions within a spell
Last modified: 2006-05-10 11:35:38 UTC
This bug is for tracking the spell versioning project. Here are some issues within sorcery that I think will need to be addressed for this project. * spells installing files sanely (this could be accomplished in part with grimoire libraries) * build api 3 may or may not need to be invoked depending on the scheme used above * cast will need to have some way of knowing if its supposed to dispel the current version(s) of the spell or not, this may or may not be something you do with cmd line args. Just something to think about for now. * must have a naming convention such that libcodex can find these spells $spell/$version has been suggested where $version is an actual sub-directory * another variable, in addition to SCRIPT_DIRECTORY/SECTION_DIRECTORY/GRIMOIRE, may need to be defined for $SCRIPT_DIRECTORY/$VERSION * codex.index or some other index must be generated so the sub-spells can be found * code for providex.index may need updating * libtablet will need updating to access the subspell files * libtablets code to source a spell will need updating, tablet itself should be content with multiple versions of a spell installed however. * libstate, depending on the naming scheme used some of these functions may need to be updating to deal with duplicate versions of the spell * what will entries in /var/state/sorcery/packages and depends look like? * if the spellname is $spell/$version then the logfile naming will have to pick the actual spell name out so the filename doesnt include a /, not a big deal, just something to think about * libdepends may need some updating * all the run_<spell_file> functions will need to be updated to follow whatever inheritence scheme is decided upon Theres probably other things that need to be looked at, but thats all I can think of for now. Let me know if you need any help or clarification on the points above, i'll gladly guide you through the twisty maze of passages in sorcery (all different), you know where to find me :-) I think the project is going to work out of the proj4 branch, if you think this can be done in the 1.13 or 1.14 timeframe we can retarget.
I like the $SPELL/$VERSION/files idea... sounds like some proper plan without much hacking... so the only thing would be for sorcery to support it. btw this would kinda break the hearts of ppl that like to have date for cvs spells... I prefer a simple cvs and maybe an option in sorcery to cast spells with version cvs/svn/whatever other versioning system we might use... I'd go always with the highest version of the spell to cast with an optional --version or maybe a user question defaulting to the latest version, dispel I think should still remove the last version installed except if more versions installed in which case should be user question with default to last before current. Also gaze would need a gaze versions spell to show the possible versions I'd split the codex.index away from this. Should have a separate versions.index for the spells. Hmmm versioning depends that would prolly work on the current system... would it not? I think libdepends would need modification here only to check(optionaly) for the version. Well even though I see no use of versioning I guess it's a good idea...
Thanks Andrew. :) Hopefully Dave and I can finish the wiki so that we can talk about it. "ruskie" ;), Versioning isn't needed, per se, but it'd certainly be nice for packages like apr, kde section, automake, libsigc++, etc. so that we don't need to keep adding spells for new/old versions.
If the spell 'name' is $spell/$version you dont need to make a version.index, codex.index can still work, it effectively makes a new spell name (which happens to contain another spell in its name). So far as I can tell that has some nice properties such that most of sorcery doesnt have to care unless it needs to. The spell name could be made some other way, like $spell--$version, so long as it is unique. As for which version to install/dispel by default, if we use $spell/$version its a no-brainer, if you say cast/dispel $spell its whatever the main spell actually is, if you want a special sub-version you say cast/dispel $spell/$version. Like eric said, this is only for spells that really need multiple versions. This should all be completely optional. I think it all boils down to a more convenient mechanism for having multiple spell versions, we've technically always had support for this via the "make another spell" method (ffmpeg/ffmpeg-cvs if they didnt conflict), but this makes it more compact and provides a few conveniences to spell writers and users. Re cvs/svn spells and the date as the version: theres no reason why $UPDATED cant be the current date (it already is a date).
Hmmm I think this is resolved???? or not?
Uhm no, if it was it'd be resolved.
changing to enhancement severity
see bug 11809 for another approach to this problem; we may or may not still need this one, I think time will tell