sm-discuss AT lists.ibiblio.org
Subject: Public SourceMage Discussion List
List archive
- 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 alsoBasically, yes about the /etc.
include a skeleton directory structure (/opt, /media, /usr,
/usr/share, 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? HowTemplated files are listed in iso.templates.
templateable are you wanting this?
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 codeWell, currently I have a rather bashy implementation, namely
would have something like this:
if __ISO_ARCH_PPC__; then
use yaboot
else
use isolinux
__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, doIIRC, all I use is a gaze -q version $spell.
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)?
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:I myself am currently involved with this, I have recently found a big
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
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 theOnce they are placed in their proper places in the skeleton and 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
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/
-
Re: [SM-Discuss] ISO generation [back on-topic]
, (continued)
- Re: [SM-Discuss] ISO generation [back on-topic], Karsten Behrmann, 01/28/2005
- Re: [SM-Discuss] ISO generation [back on-topic], David Kowis, 01/28/2005
- Re: [SM-Discuss] ISO generation [back on-topic], Eric Sandall, 01/28/2005
- Re: [SM-Discuss] ISO generation [back on-topic], Karsten Behrmann, 01/28/2005
- Re: [SM-Discuss] ISO generation, Karsten Behrmann, 01/26/2005
- Re: [SM-Discuss] ISO generation, Andrew, 01/26/2005
-
Re: [SM-Discuss] ISO generation,
Karsten Behrmann, 01/27/2005
-
Re: [SM-Discuss] ISO generation,
Eric Sandall, 01/27/2005
- Re: [SM-Discuss] ISO generation, Karsten Behrmann, 01/27/2005
-
Re: [SM-Discuss] ISO generation,
Paul Mahon, 01/27/2005
-
Re: [SM-Discuss] ISO generation,
Eric Sandall, 01/27/2005
- Re: [SM-Discuss] ISO generation, David Kowis, 01/27/2005
-
Re: [SM-Discuss] ISO generation,
Paul Mahon, 01/27/2005
- Re: [SM-Discuss] ISO generation, Seth Alan Woolley, 01/27/2005
-
Re: [SM-Discuss] ISO generation,
Eric Sandall, 01/27/2005
- Re: [SM-Discuss] ISO generation, Andrew, 01/27/2005
-
Re: [SM-Discuss] ISO generation,
Eric Sandall, 01/27/2005
-
Re: [SM-Discuss] ISO generation,
Eric Sandall, 01/27/2005
Archive powered by MHonArc 2.6.24.