Public SourceMage Discussion List

[Paul <dufflebunk AT dufflebunk.homeip.net>]

The desired way of documenting is using bashdoc, it tries to look like
javadoc. However, many of the scripts have not been converted yet. If
you're looking to familiarise yourself, converting a couple (and
documenting the undocumented functions) would probably help your
understanding. The sorcery docs on my site are a litle out of date, but
anyone can generate their own fairly quickly.

http://dufflebunk.homeip.net/~dufflebunk/sorcerer/docs/

On Wed, 2004-02-04 at 00:24, Casey Harkins wrote:
> On Wed, 4 Feb 2004, Hamish Greig wrote:
> > Could someone please handcuff casey to a SMGL workstation ?
> > Casey, love your work and want more of it !
> 
> I'd love it. Its the other crap I have to do at work that keeps me away
> from SMGL that I don't like! What I really need to do is find some time to
> sit down and familiarize myself with the sorcery scripts so I can help out
> the overworked sorcery team.
> 
> I asked this once a while ago, but its obvious that the scripts have some
> sort of tags for a documentation generation tool. Which tool? I need to
> get me some sorcery api docs!
> 
> > If I am to successfully change our ISO to a set of binary cache tarballs 
> > instead of the monolithic image.tar.bz2 I will come up against some of 
> > the 
> > same dependency problems you must have encountered.
> 
> The biggest issue right now with the binary cache/packages is that there 
> are changes that are made to files (mostly in /etc) that are not tracked 
> by sorcery. These changes don't get made if you "resurrect" from the 
> binary cache. My (not-so-elegant) solution was to create custom 
> POST_INSTALL's within the binary grimoire for spells that did this so that 
> the changes could be made when installing with the binary grimoire. 
> 
> I be posting my code somewhere at some point. I called the tool binery. It
> can:
> 
> - create a "binery" grimoire
> 
> - add spells to a binery grimoire, which must be installed on the current 
> machine (dependencies added automatically)
> 
> - remove spells from a binery grimoire
> 
> - update the binery spool, which updates the spell details for each spell
> in the binery grimoire that has changed since the last update, creates a
> binary package for it, packages the grimoire and copies the sorcery
> scripts package into the binery spool
> 
> The client machines just scribe add this grimoire, set their BASE_URL to
> the spool created by binery on the reference machine (binery itself can
> set the URL's within the spells so that using sorcery's BASE_URL is
> unnecessary).
> 
> Then you just scribe add the second grimoire with the meta spells and 
> you're good to go!
> 
> 
> > At some convenient time (read later, post 1.0) I would love to discuss 
> > some 
> > ideas with you, things like a wrapper around the cache tarball that lists 
> > it's depends, so a form of resurrect can be used to satisfy those depends 
> > more easily.
> 
> I like where you're going with this. I'm not a fan of how sorcery will
> leave cruft in /var/state/depends after a spell is dispelled (I think it
> still does this). Doesn't exactly represent the "state" of the system.  
> However, it can't exactly be removed if sorcery might resurrect it later.
> With this, my binery tool is essentially useless if sorcery could be
> forced to run in a "resurrect-only" mode.
> 
> Anyway, we've taken this "theme" thread waaaaay off topic. Looking forward 
> to 1.0 and post-1.0 and 10.0 and post-10.0...
> 
> -casey
> 
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss
-- 
De mortuis nihil nisi bonum.

Attachment: signature.asc
Description: This is a digitally signed message part