Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] sorcery purists do not read! (fwd)

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Dufflebunk <dufflebunk AT dufflebunk.homeip.net>
  • To: SM-Discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] sorcery purists do not read! (fwd)
  • Date: Mon, 9 Dec 2002 08:18:39 -0500 (EST)

You know, we do always need more bashers for sorcery development...
More comments below:

On Mon, 9 Dec 2002, Mark Andrews wrote:

> Hello Mads,
>
> Wednesday, December 4, 2002, 10:42:32 PM, you wrote:
>
> ML> In fact I think that one feature (very post 1.0) that should be
Could someone refresh my memory? What is "that"?

> ML> considered, is depending on specific options, somehow (an extreme
> ML> example could be c++ code depending on the c++ support in gcc,
> ML> allowing systems without c++ support to be built).
>
> This is something that is pretty much a prerequiste for handling
> automatic hardware configuration properly. And something that I've
> been pondering how to handle best for some time. I've mentioned before
> about possibly needing hardware spells and these obviously need to
> depend on options to be handled cleanly. Think of a USB device that
> may well depend on it's own driver, the hotplug stuff plus a kernel
> compiled with USB support and you'll see where I'm going with this.
If there was h/w detection, the spell could provide things like i686, and
USB, and stuff like that.Doing something like that should integrate
easily into the grimoire and other spells.

>
> ML> Anyway, I'll stop before I get too far of track.
>
> Doubt you'll get as far me. I'm currently working through Linux from
> Scratch creating my own versions of summon, gaze, scribe and a
> grimoire as I go. And I'm using zsh not bash...
Why would you want to use zsh? That's a serious question. I don't know
zsh.

>
> I'm working on providing full dependancies, including config options
> where appropriate (particularly useful for handling binaries as well),
> and full tracking including extract, configure, build and install
> stages.
>
> Before anyone gets on my back about this, I'm doing it as a learning
> experience - I've nearly worn out my m, a & n keys. Though a few ideas
> have come up that would be nice to have in sorcery.
Why the HELL are you wasting your time with ... ;) hee hee
Dare I ask: "m"?

>
> Like my ua command which does an extension based (recursive)
> unarchive command - so things like
>
> ua -d /directory file1.tar.gz file2.patch.bz2
>
> produce a patched source directory. ua should even handle a
> patch.tar.Z.gz.bz2 file properly if someone was daft enough to make
> one. It's extensible to allow extra archive formats to be added
> (I'm planning rpm & pkg at some point!) - the recursive part just adds
> piped commands to a TEMPCMD variable to be eval'd at the end of the
> top layer. The plan is that the bzip2 spell manages it's entry in the
> ua command and so on..
Hmm, interesting.
As a side note isn't .Z the same as .gz?

>
> I've also seperated the source file information from details into
> seperate '.info' files. This allows for things like:
>
> if [[ -e ${FILECACHE}/linux-2.4.19.tar.gz ]]; then
> store ${SPELLDIR}/src/linux-2.4.20.tar.gz.info SKIPFILE 1
> store ${SPELLDIR}/src/linux-2.4.19.tar.gz.info SKIPFILE 0
> store ${SPELLDIR}/src/patch-2.4.19-2.4.20.patch.bz2.info" SKIPFILE 0
> else
> store ${SPELLDIR}/src/linux-2.4.20.tar.gz.info SKIPFILE 0
> store ${SPELLDIR}/src/linux-2.4.19.tar.gz.info SKIPFILE 1
> store ${SPELLDIR}/src/patch-2.4.19-2.4.20.patch.bz2.info SKIPFILE 1
> fi
>
> And during the download processing a SKIPFILE=1 setting causes the
> file to be skipped. I've also moved the md5sum into these info files
> along with the download location. I'm checking the download md5sum
> rather than the extracted one. As far as I'm concerned if it ain't
> a valid archive then I don't want to waste any more CPU on it ;-)
>
> I've included versions in the spell names and moved the generic spell
> name (linux etc) into a variable in the details file and I'm using a
> flat grimoire. So the above would be from a grimoire/linux-2.4.20 spell.
So in order to cast a spell your scripts have to look through all the
files in the flat grimoire to find the one with the SPELL=linux (or equiv)
line? Or do you always have the first part of the name being the spell?

>
> Mirror handling I've moved out of spells completely. The spell
> specifies the authorative location and the url is processed against a
> mirror list which can swap the first part of the url out when
> required. So a GNU-mirrors file would have ftp://ftp.gnu.org/pub/gnu/
> plus the equivalent path section for the mirrors listed. Well that's
> the plan.. My current alternative summon just uses cached files 8-(
>
> I also seem to be moving away from having build, pre-build etc stuff
> under specific names. The names of .info & .action files is
> independant of the actual filenames (to allow sys-v style filename
> based ordering to apply patches at the right time) so it's actually
> very easy to do spells with configure and build scripts at the
> appropriate points (.action files I'm calling them currently). I'm
> thinking of adding a STAGE= field to all these scripts to allow
> selective actions.
A possible problem with this is you lose stucture. You have more
flexibility, but less stucture. Good if you have the self control, but bad
if you open it up to everyone to make spells.

>
> So .info files would be STAGE=download:extract (or
> STAGE=download:install for binaries), build files STAGE=compile,
> STAGE=download for the SKIPFILE configuration script above (with a
> 00skipfiles.action filename) and so on.
>
> A simple $(grep -H "STAGE=.*extract" ${SPELLDIR}/src/*) then gives a
> complete ordered list of scripts to 'run' to create the build directory.
> $(ls ${SPELLDIR}/src/*) gives the list to do everything - download,
> extract, configure, build, install.. 'run' sometimes means just that
> (.action), others (.info files) it means process the data in the file
> using a particular routine.
>
> But back to the original point.. One of these data scripts (.depend)
> will support providing the compile options required for a dependancy.
> I'm thinking one spellname.depend file per dependancy so variables to
> control version specific depends, config depends etc go into that
> file. So a hardware spell may just be a .depend for specific kernel
> options.
>
> And you thought you were off the beaten track?! <big grin>
So long as you're having fun, I don't think anyone will begrudge you your
path abuse ;)

>
> If anyone's wondering, I'm about halfway through the static stage of
> LFS at the moment with auto extraction but manual builds. I'm going to
> add auto builds in at the dynamic stage when I'm a bit clearer on just
> what is needed by the various configure & build methods.
>
>

--


Quidquid latine dictum sit, altum sonatur.
-----------------
PGP public key at
http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x3327A9A5
F1







Archive powered by MHonArc 2.6.24.

Top of Page