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 10:26:08 -0800

>
> >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.
> >
> >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?
>
> 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).

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

These are conflicting statements about general software design
principles. Karsten's argument says that having architectural differences
seperated into configuration files will lead to less work, while Benoit's
argument says that having all the architectural differences glommed into
the same script will mean less work (but he's said theres no hardcoded
stuff in his scripts).

I would have to say its a better approach for the long term to have
our software be modular so that architectural differences can be
encapsulated in those modules and configuration data. Then the higher
level tasks can be driven by configuration details to use whatever pieces
of modular code are necessary. In the end, the modular approach becomes
less complex than the more monolithic approach of having everything in
one script for "ease of maintainence".

For example there could be a configuration entry for what bootloaders
to use, the x86 would have lilo and grub, the ppc would have yaboot,
and the higher level scripts wouldnt need to know the difference.
Or as benoit alludes to, the way mkisofs is used varies between platforms
so that can be encapsulated in a module rather than a case statement.


-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: pgpQ20tRPnbSL.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page