Proposed Spec

Problem: # If a spell is cast, then the spell is updated, the *REMOVE scripts will get replaced with the new version. This may potentialy cause spells to dispel badly in the update. A similar thing happens when spells are removed from the grimoire. # Spells have various settings which are scatered around the FS, this includes:

# Searching for what a single spell depends on currently consists of looking through a single file with all depends for all spells. This is inefficient. # Installing via a cached tarball (resurrect) has the following potential problems:

Proposed Solution: Create a grimoire wich holds the installed version of each installed spell.

The proposed base directory for the installed grimoire is $STATE_ROOT/var/state/sorcery/installed Subdirectories will be spell names. Each spell directory will contain one or more timestamps indicating when the spell was installed. This is in anticipation for the day we allow a spell to be installed several times. Each of these directories will be independent of one-another. From here forward a $INSTALLED_GRIMOIRE/$SPELL/$TIMESTAMP directory will be refered to as a "spell's directory". It is illegal for a $INSTALL_GRIMOIRE/$SPELL directory to exist and be empty. There should be a cleanse function to verify this is the case.

The spell's directory should also hold spell specific state data such as the following: # A copy of all spell files # A copy of all files from the section directory it was found in # A copy of all files from the grimoire directory it was found in (see notes below about space usage) # Dependencies used to cast, # Persistent variables used to cast, # Arch info when cast, # Compiler settings for cast, # Grimoire name, URLs used with the spell # Version of the spell # Compile log (or a link to?) # Install log (or a link to?) # Install date/time # (new) Spell level filter files (see spec yet to be written on this topic) We may also want to include: # (Link to) binary tarball # (Link to) source tarballs # (Link to) MD5 sum log

Obsoletes: The following files may be obsoleted:

  • /var/state/sorcery/depends
  • /var/state/sorcery/packages

Although we may want to keep those files around anyways since they help with going the other way around (like finding out what packages depend on Foo). Note, this may become more difficult when multiple versions of a spell are installed. For now the depends and packages files will serve as a cache to the installed grimoire cleanse should verify that they are in fact identical.

Space usage: Each spell directory will have copies of grimoire and section level files. We want to keep the files frozen for each spell (hence individual copies). But we also realize that 1) this takes a lot of space and 2) they dont change often. Our solution to minimizing space consumption is to utilize hardlinks. There will be a cleanse feature to coelesce files. Files will be deemed identical based on md5sum. This could easily be done using our hash table implemention. For each file we find, take its md5sum then store the md5 and filename in the hash table. If the md5sum is already a key into the hash table, its subsequent value is a file with the hardlink. At which point the duplicate file can be replaced with a hardlink.

When dispelling, dispel should look in the install grimoire for any *REMOVE scripts. The various spell state which should persist should be moved to new abandoned data directory(s) similar to what happens with depends data already. After dispelling, the spell directory in the installed grimoire should no longer exist. If that spell directory was the only timestamp for that spell, the base spell directory is removed as well (note until we allow multiple spells to be installed at once this will always be true).

When casting, the default answers to depends questsions will have to lookup previous answers in the installed grimoire if it exists (or in abandoned info, as is already the case with depends). It should also question about changes in the arch and compile settings. If the spell doesn't exist in the installed grimoire, the abandoned data directory should be checked. After the old version has been dispelled (and it's directory removed from the installed grimoire) a new directory should be created, with the above information included.

Cache tarballs will include the installed grimoire, and resurrect will be enhanced to utilize it if it exists, however resurrect's use of the installed grimoire will be completely optional and in its absense will just do less checking etc. This will be discussed on another spec related to resurrect improvements,

Attach additional commenta under here


Some of the problems we have to solve are:

  • spells that track files they shouldnt. The normal solution is to put commands in PRE_REMOVE

to pull the offending files out of the install log so they aren't incorrectly removed. With the installed grimoire there is no way to fix the offending spell down the road because we use the installed spells PRE_REMOVE. A PRE_PRE_REMOVE was suggested, but this problem remains at large.

InstallGrimoire (last edited 2008-09-22 23:34:47 by localhost)