Skip to Content.
Sympa Menu

sm-discuss - [SM-Discuss] ISO spell installation method (Was: [Private mail]Cauldron Team Email Meeting)

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: [SM-Discuss] ISO spell installation method (Was: [Private mail]Cauldron Team Email Meeting)
  • Date: Fri, 3 Jun 2005 21:17:15 +0200

Hi everyone!
We're doing some thinking on the ISO team about where we should go and
be with the ISOs by 1.0.
As I'm doing the installer, I've done some thinking on how the installer
should install the spells. We're looking at several requirements:
1. Ease to maintain (fix and update)
2. Keep ISO size down
3. It should work

Okay, let's summarize... we have several possibilities:
1. regular un-tar: (from cache tarballs)
PRO:
- standard method, might be the easiest to get going nicely with little
effort (so that we can concentrate on other, important stuff)
- been done before, so should work
CONTRA:
- un-elegant, inflexible and hard to maintain if coded badly

2. regular un-tar using busybox
PRO:
- almost as easy as 1.
- smaller ISO
CONTRA:
- one more spell to specially configure for ISO use
- not all users may be familiar with the reduced capabilities (->rescue CD)
- still as inelegant

3. un-tar but copy everything already in the ISO system from there
(e.g. cp /bin/bash /mnt/root/bin/bash instead of untarring it)
PRO:
- standard method with some modification (pass through install log,
if it exists on the ISO, copy, then extract tarball)
- high reduction of ISO size
- might even be faster (not such a large data volume to unbzip2)
CONTRA:
- added code overhead (though should be condenseable to not many lines)
- rescueing a system using an ISO using tarball becomes a little harder,
we'll definitely need to provide a script to do it
- generating the cache tarballs gets a tad harder

4. use the full sorcery suite to install_root resurrect cleanly
PRO:
- nice, standardized method
- uses code I don't have to write and maintain ;-)
- automatically takes advantage of POST_RESURRECT scripts
CONTRA:
- needs more programs on the ISO (cast needs make)
- reduced flexibility (e.g. we can't keep it from casting a dependency)
- still a little bit non-intended use... resurrect is meant to restore,
not to install

5. make the ISO a full build system and INSTALL_ROOT
PRO:
- Really source-based
- ISO becomes more of a rescue disk when it can compile by itself
- extremely elegant
CONTRA:
- Will probably be a hell of a lot of work getting it to run
- Even bigger ISO (though having net stuff on might enable us to download
the sources on install
- Very time-consuming install
- Also not quite flexible

Okay, so much for a small overview of what I'm considering.
Now for what I'm thinking of implementing.

Currently, my main focus is to get a maintainable installer out ASAP.
This definitely rules out 5., which would require a good bunch of testing.

I would myself just go for 1., because it seems to me as the way that will
be quickest to just get to work, so that we can get on to make a nice
rest of the installer.
I know some people want me to do 4., but I'm not entirely comfortable that
it might not harbor some hidden ton of work. Also, I'd rather not have more
automatisms than I plan to. Also, even this method will still need
workarounds in the code (e.g. openssh key generation).

If we eventually want to crank the ISO size down, I'd be more comfortable
with 3. than with 2., simply because
- I think 3. gives more of a gain
- I'd rather not get used to the reduced capabilities of the busybox tools
- It does not really seem so hard to
while read file ;do
if [ -e $file ] ;then cp --parents -f $file ${TARGET}
done <$install_log

But I'd first just use the quick-and-dirty method 1.
I will try to code so that it can be easily ripped out and replaced by any
of the given methods, but I just want this baby out and running before I
start running through changes that might take a while.
Of course, when there is sufficient opinion that I should do a different
method from the start, I'll bow to PL/TL/reason/the majority and work that
way.

Enough written for now.
So Far,
Karsten "BearPerson" Behrmann

Attachment: pgpwlKSSXlPvp.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page