Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Functional "theme" instead of cosmetic

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Casey Harkins <charkins AT upl.cs.wisc.edu>
  • To: Hamish Greig <hgreig AT bigpond.net.au>
  • Cc: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Functional "theme" instead of cosmetic
  • Date: Tue, 3 Feb 2004 23:24:35 -0600 (CST)



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





Archive powered by MHonArc 2.6.24.

Top of Page