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: Karsten Behrmann <BearPerson AT gmx.net>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] ISO generation
  • Date: Thu, 27 Jan 2005 13:09:30 +0100

On Wed, 26 Jan 2005 18:41:32 -0800 (PST)
Eric Sandall <eric AT sandall.us> wrote:
> > 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.)?
Basically, yes about the /etc.
All alien files in /etc are to be in the skeleton.
We have a technical problem however with a skeleton directory structure,
as perforce does not do empty directories; a directory solely exists because
something is in it. Therefore there is the file iso.dirs in my scripts
that specifies a directory structure to be created.

>
> > 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?
Templated files are listed in iso.templates.
s/// templates are in smgl.templates (for things like ISO version and such)
>
> > 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
Well, currently I have a rather bashy implementation, namely
__SMGL_TEMPLATE_ONLY_ppc__use yaboot
__SMGL_TEMPLATE_ONLY_x86__use isolinux
in the files. Of course things get complicated if we need files for one
arch and not for another, an issue I have not yet resolved.
Maybe both the alternate-file (file.x86 etc) and the templated-file
schemes can be used in parrallel

> Could this be merged with the current scripts without too much fuss?
Yeah, it would just walk along the almost-finished ISO tree picking out
the templated files and modifying them.

> 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)?
IIRC, all I use is a gaze -q version $spell.
I might use cast with install_root, but I am rather put off by the fact
that some people say glibc doesn't like it.
I would basically be resurrecting to a bare tmp location, and right now
I'm more confident simply unpacking the cache tarballs myself for that;
I don't know what gain could be had by using cast in this stage.

> 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
I myself am currently involved with this, I have recently found a big
source of a big bug on my ISO, and I am pretty confident most of
the bugs can be ironed out. But if the majority wishes us to use
the "current scripts", I will try to merge as much of my improvements
over as makes sense and maintain those or something else if they are
already being maintained by benoit.
>
> 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
Once they are placed in their proper places in the skeleton and the
new scripts modified to give them the info files they need, integration
should be pretty painless.

So Far,
Karsten

p.s.: Thanks for opening the regular discussion again.

Attachment: pgp0A4mZ3F5ZY.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page