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: Andrew <afrayedknot AT thefrayedknot.armory.com>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] ISO generation
  • Date: Wed, 26 Jan 2005 13:56:34 -0800

On Wed, Jan 26, 2005 at 10:31:31PM +0100, Benoit PAPILLAULT wrote:
> Andrew a ?crit :
> >karsten said (paraphrasing) we'll seperate architectural differences
> >into config files.
> >
> >benoit said (paraphrasing) we should have one script since its less
> >complex since there is less maintainence work
>
> No. I said it could be simpler to use some switch/case construction for
> the mkisofs generation, not for the whole thing. And I say so only for
> arch-specific stuff which are limited in the whole ISO generation
> process. Don't let people think that I'm saying a "big script" is the
> way to go. I don't think it is.

Heres what you said...
>>> To make the script portable amongst various architecture, i think it's
>>> quite complex. Some files exist only on some arch (isolinux.cfg for
>>> instance). A main difference between ppc and x86 too is the way the .iso
>>> is generating with mkisofs. However, having the same script for all
>>> architecture is a good way to lower the maintenance work on the script
>>> (since you maintain only one set of scripts, instead of one set per arch).

I would be inclined to say that theres more differences between the
two isos than just the actual process of making the iso filesystem,
such as versions and what gets installed (bootloader anyone?) I think
that might be where the conflict is coming from, your stance is there
isnt a lot of difference so having on set of scripts is sufficient, on
the other hand, maybe theres more differences in which case as time goes
on one non-modular set of scripts is going to get unwieldy, especially
as we add more architectures down the road...(sparc, hurd, amd64, anyone?)

In anycase Im sorry if I portrayed your code as a "big script" I just
happen to think that its better to be modular than to over-use case
statements everywhere, and encapsulate architectural differences in
them. Modularizing that stuff out results in higher level stuff staying
higher level, and low level stuff staying low level, which is a good thing
(IMO).

(imagine if in sorcery summon called wget/rsync/cvs/svn directly through
a case statement, or imagine if the linux vfs didnt exist and every
filesystem had to add entries in a switch statement, blegh!)

>
<snip>
>
> You deserve to write some design documentation for the Cauldron Team.
> Since we are discussing what will be our next generation script, that
> would be really helpful. Really.
>
<joke>
Oh, please enlighten me, why do I deserve such a high honor oh esteemed
member of the cauldron team? :-) I guess you guys really dont want any new
sorcery features if you want me to design your iso generator...
</joke>

In all seriousness Im not your doc writer, sorry, but i thought you were
having this talk to figure out what your new setup will be, or at least,
who's base code you're going to start with. BTW karsten's stuff is
reasonably design doc'ed on the wiki.


-Andrew

--
__________________________________________________________________________
|Andrew D. Stitt | astitt at sourcemage.org |
|irc: afrayedknot | afrayedknot at t.armory.com |
|aim: thefrayedknot or iteratorplusplus | acedit at armory.com |
|Sorcery Team Lead | ftp://t.armory.com/ |
--------------------------------------------------------------------------

Attachment: pgpZ0AFSf8x4E.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page