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 20:54:24 +0100

> 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. ;)
erm, what's your point?

> >> 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?
I define Templated files as those files that use smgl.templates.
No use to go look at all files on the ISO for templates,
so the file iso.templates should list all files that contain templates
(hereafter called "templated files"). So per definition,
only templated files use smgl.templates.

> > 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?
Not if the templates are not in a bash file but in a config file for example.
In order to get good ifdef/else/endif constructs, I'd need to muck
around with m4 or some other stuff, that might actually break
because of some syntax coincidence in a templated file. Therefore,
I prefer my templates that specify how the files should be modified.

> >> 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?
The template part looks at the directory tree with all files in place as
they will be on the ISO. AFAIK, benoits scripts also offer this situation
(immediately before the run of mkisofs if need be)

> > 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.
Yup, when all this trickles down to stable we'll be all fat and happy.
Until then, I'm afraid we'll have to get by with what we have.

<big snip>
> 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. :)
As may be expected, I'd prefer using my scripts, but I'm open to
discussion.

> -sandalle
Karsten

Attachment: pgppkXTkYuEUR.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page