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: Thu, 27 Jan 2005 09:25:55 -0800 (PST)

On Thu, 27 Jan 2005, Karsten Behrmann wrote:
On Wed, 26 Jan 2005 18:41:32 -0800 (PST) Eric Sandall <eric AT sandall.us> wrote:
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.

Would it be easier to just have a tarball of empty directories and
untar that in the iso_root? The iso.dirs file would be easier to
maintain and modify, so the tarball probably isn't that great of an
idea. ;)

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)

Templated files are the /only/ files that use smgl.templates?

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

Wouldn't it be better to define "variables" for architectures:
e.g.
__SMGL_ARCH_PPC__
__SMGL_ARCH_X86__

and then have code later on with:
if __SMGL_ARCH_PPC__; then
cast yaboot # this should resurrect yaboot
elif __SMGL_ARCH_X86__; then
cast isolinux # this should resurrect isolinux
else
message "${MESSAGE_COLOR}You forgot to define an
architecture!${DEFAULT_COLOR}" &&
return 1
fi

Or is that not quite what the goal of templates is?

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.

Doesn't your code use different behaviour for installing? How would
that merge be handled?

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.

That is fixed in devel for glibc, but then another problem is caused.
:( See http://bugs.sourcemage.org/show_bug.cgi?id=7831. Once the
improved resurrect (and even tablet) code is in stable Sorcery most of
the state information for spells will be taken care of for you and
reduce your work.

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.

Which is what this thread is meant to resolve. :)

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.

Painless is good.

So Far,
Karsten

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

Thanks for opening it up. :)

What are other people's opinions? I think it'd be a good idea to use
Karsten's method to modify Benoit's scripts after applying David's
split of smgl.install, but that may be asking too much. :)

-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