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: Eric Sandall <eric AT sandall.us>
  • To: SM Discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] ISO generation
  • Date: Wed, 26 Jan 2005 18:41:32 -0800 (PST)

On Wed, 26 Jan 2005, Karsten Behrmann wrote:
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.

Agreed.

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.

e.g. the /etc directory would be in the skeleton? Would this also
include a skeleton directory structure (/opt, /media, /usr,
/usr/share, etc.)?

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.

Would the templates be defined in the same location as the config? How
templateable are you wanting this?

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?

So if we defined, say: __ISO_ARCH_PPC__, then the bootloader code
would have something like this:

if __ISO_ARCH_PPC__; then
use yaboot
else
use isolinux

And maybe some if's for SPARC, x86_64, etc. later on.

Could this be merged with the current scripts without too much fuss?

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)

Well, I guess that's it for now,
So Far,

Thanks for the start. ;) I've been a bit busy this week, my apologies.

Karsten

Benoit, I recall that you were looking at install_root. Karsten, do
your scripts already use install_root? If our ISO scripts (either
Benoit's or Karsten's) can/do use Sorcery to install spells then
install_root is already taken care of. Do either of your scripts
use Sorcery (even if it's partly hacked up)?

Which of the following do people want our ISO Team to work on:
1) Use the already working (a.k.a. the scripts Benoit is maintaining,
herafter referred to as the "current scripts")
scripts, fix bugs filed, and produce ISOs using these scripts or

2) Use Karsten's scripts, fixing bugs filed against his ISOs, and
begin producing ISOs with these scripts (herafter referred to as the
"new scripts") or

3) Use the template idea from the new scripts and apply it to the
current scripts or

4) Merge David Kowis' modularization of smgl.install into the current
scripts or

5) Merge David Kowis' modularization of smgl.install into the new
scripts

-sandalle

--
Eric Sandall | Source Mage GNU/Linux Developer
eric AT sandall.us | http://www.sourcemage.org/
http://eric.sandall.us/ | SysAdmin @ Inst. Shock Physics @ WSU
http://counter.li.org/ #196285 | http://www.shock.wsu.edu/




Archive powered by MHonArc 2.6.24.

Top of Page