an overview of buildinstall

[rpjday <rpjday mindspring com>]

  so here's what i've discovered about buildinstall thus far --
feel free to jump in and add any comments.  also, there's a few
more advanced questions at the end, if anyone's feeling clever.

  the purpose of buildinstall is to take a single directory,
RedHat/RPMS, and build installation files and directories around
it, including the images/ and dosutils/ directories, and the 
RedHat/base directory which will include the installer images.
in short,

what you start with:

  RedHat/
         RPMS/
              (all your RPMs)

what you finish with:

  dosutils/*
  images/*
  RedHat/
         RPMS/
              (all your RPMs)
         base/
              hdstg1.img
              netstg1.img
              stage2.img

you can then use this as a starting point in building your own 
install CDs by adding a "comps" file, running "genhdlist" and so on.

  all of the essential scripts are part of the anaconda-runtime RPM,
so make sure that's installed -- the scripts themselves live in
/usr/lib/anaconda-runtime, so (as root) add that to your search path
for convenience, then (keeping it simple):

  # cd (your build directory)
  # ls
  RedHat
  # buildinstall .

go grab a coffee, and by the time you get back, you should have the
directory structure above.  notice that i kept it simple and didn't
add any options to the buildinstall invocation.  that will come later
after i figure it out.

curious issues
------- ------

1) the buildinstall script refers to "COMPNAME=dist-7.0" and a default
  VERSION of 7.1.  should this be updated to reflect 7.2?  if not, what
  do they refer to?

2) sadly, it appears that you have to run buildinstall as root, even if
  you wanted to do all this under a non-root user account.  bummer.

3) buildinstall eventually calls "mk-images", which in turn calls
  "mk-images.{ARCH}" for your architecture to build the files in the
  images/ directory.  does that same script also build the installer
  images under base/ ??

4) note that you don't have to say anything about the modules you want
  to include, either in boot.img or the installer images.  i'm assuming
  that this is all done automatically, since running buildinstall
  generates a slew of messages like

    Module dmx319ld not found in kernel rpm
    Module fcal not found in kernel rpm
    Module pluto not found in kernel rpm
    Module qlogicpti not found in kernel rpm

  i'm assuming that these are perfectly normal, right?  and no cause
  for alarm.

  so do you have any control over which modules are included?  if you
  run buildinstall normally, it appears not.

5) (tricky)  this appears to be a bug, or at least an annoying feature,
  of buildinstall.  consider the code excerpt near the top:

--------------------------------------------------------

UPD_INSTROOT=./upd-instroot
MK_IMAGES=./mk-images

BUILDARCH=`rpm -qp --qf "%{ARCH}" $p/RedHat/RPMS/anaconda-runtime-[0-9]*`

if [ ! -f $UPD_INSTROOT ]; then
    cd $BUILDINSTDIR       <-------- THIS cd statement, if it's run ...
    rpm2cpio $p/RedHat/RPMS/anaconda-runtime-[0-9]* | cpio --quiet -iumd ./usr/lib/anaconda-runtime/upd-instroot usr/lib/anaconda-runtime/upd-instroot
    mv usr/lib/anaconda-runtime/upd-instroot .
    rm -rf usr
else
    cp -a $UPD_INSTROOT $BUILDINSTDIR/upd-instroot
fi
UPD_INSTROOT=$BUILDINSTDIR/upd-instroot

if [ ! -f $MK_IMAGES ]; then     <------- ... messes up this test
    cd $BUILDINSTDIR
    rpm2cpio $p/RedHat/RPMS/anaconda-runtime-[0-9]* | cpio --quiet -iumd ./usr/lib/anaconda-runtime/mk-images* usr/lib/anaconda-runtime/mk-images*
    mv usr/lib/anaconda-runtime/mk-images* .
    rm -rf usr
else
    cp $MK_IMAGES* $BUILDINSTDIR/
fi
MK_IMAGES=$BUILDINSTDIR/mk-images

-------------------------------------------------

  what the above is doing is giving you the freedom to copy the 
upd-instroot script into the build directory.  if you do, it will be
used for the subsequent build.  why do you care?  you might want
to customize it, or (as i did) put debugging statements into it to 
see what was going on.  if that script isn't there, buildinstall
just extracts it from the anaconda-runtime RPM.

  the same thing is done for the mk-images script, in case you want
to make some changes to that one.  *however*, if for one reason or
another, you make a copy of the mk-images* scripts but *not* the
upd-instroot script, buildinstall will not use your personal copy
of mk-images, since it will already have "cd"ed into the BUILDINSTDIR
directory to get its own copy of upd-instroot.  in short, the first "cd"
to get a copy of upd-instroot will mess up the subsequent test to see
if you have your own copy of mk-images.

  should i be annoyed by this?  or should i have expected it?
comments?  

rday