Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] ISO generation

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Benoit PAPILLAULT <benoit.papillault AT sourcemage.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] ISO generation
  • Date: Wed, 26 Jan 2005 17:23:17 +0100

Hi Karsten,

I'm glad you open the discussion! I was waiting for our PL or TL, but so far, nothing comes. I'll add my comments. Since David Kowis has volonteer to host the ISO generation scripts, I think his comment are required. Moreover, he should be added to the Cauldron Team. We should also add the installer script in the discussion, since it's part of the ISO.

Karsten Behrmann a écrit :
Hi guys, hi Cauldron/ISO team!
I guess I'll start the discussion on ISO generation scripts open for
everyone. Just to make it clear, I do not favor my scripts any way else
than that they include what I think is sensible, they represent (mostly)
my opinion of things. I don't care who wrote the scripts I use and
maintain as long as they do what they should.
And here's a list of things that IMO they should:

1. clearly seperate config/code:
For routine changes (adding of a spell or file) you should only have
to modify a clearly defined configuration file, not search in some
bash code for the for loop where the files/dirs are in.

Yes! For instance, we should get rid of the hardcoded path in //sgl/cauldron/devel/iso/data/bearscripts/initrd.files.

2. use the skeleton:
I just like the idea. If any non-spell (or overriding a spell) file
needs to be on the ISO, it's in a directory tree representing the ISO.
If any file needs changing, it can be found quickly. No more cat <<EOF's.

Yes.

3. use templates:
This is the logical consequence of 2.: There are bound to be some files
that contain more-or-less dynamic content. Version numbers, Architectures
and lines differing in different architectures will have to be inserted
after copying the skeleton. I'm working on good code for it though.

We could maybe solve the different-arch problem by creating several files,
like isolinux.cfg.ppc and such. That could be rather easily coded,
but might be a second more work to maintain. Comments?

To make the script portable amongst various architecture, i think it's quite complex. Some files exist only on some arch (isolinux.cfg for instance). A main difference between ppc and x86 too is the way the .iso is generating with mkisofs. However, having the same script for all architecture is a good way to lower the maintenance work on the script (since you maintain only one set of scripts, instead of one set per arch).

And one day, we might even support
4. automagical chroot maintenance:
The scripts should one day detect outdated spells and recast them,
making sure no dependencies creep in, using the spell config from the
official cauldron stuff and so on. Using cast in ISO creation would
be a beginning. Of course this will make the scripts require to be
run in a chroot (or another environment that doesn't care having
sorcery configs changed and sorcery code patched)

Maybe a simple sorcery system-update could be enought?

Benoit PAPILLAULT, ISO guru




Archive powered by MHonArc 2.6.24.

Top of Page