[RFC] The future of LH_BINARY_IMAGES

[chris at chris-lamb.co.uk (Chris Lamb)]

Hi,

I just went to see how we could fix up handling of LH_BINARY_IMAGES. This
is the configuration variable which determines whether the resulting binary
image is a ISO, "usb-hdd" or netboot image. (It is set by the "-b" and
"--binary-images" lh_config parameters if you are more familiar with that.)

The problem is that the code is rather undecided whether this variable is a
list of images to build or a single image type: a number of places assume
the former, and some the latter.

I propose that we drop the (partial) support for LH_BINARY_IMAGES being a
list because:

 * I don't see how some of the lh_binary_* helpers can even support it being
   list..

   For example, lh_binary_syslinux does completely different things
   depending on the binary image type, so the side effects of this helper
   cannot be invariant for all image types. Thus, we cannot simply re-use the
   same binary/ directory for each item in LH_BINARY_IMAGES, not least of all
   because we cannot export overriding vars to sub-helpers due to the way
   configuration files take precedence over environment vars.

 * You can implement the intended functionality outside of live-helper with:

      IMAGE_TYPES="iso net tar usb-hdd"

      set -- ${IMAGE_TYPES}
      lh config -b ${1}
      shift

      lh build

      for X in ${@}
      do
        lh clean --binary
        lh config -b ${X}
        lh binary
      done

   .. or similar. This doesn't regenerate the rootfs due to caching. 

 * It seems to me that the use-case for a "one-shot" build of all image
   types is somewhat restricted to people autobuilding images, where they are
   sure to be scripting other parts of the build, such as renaming results
   and moving things into web-accessible areas. If they are scripting things
   like that, then it is not very much more ugly/LoC to include a variation
   on the above snippet.

 * Nobody is relying on this feature (unless they have a found a code path
   and configuration permutation that supports it, which is highly unlikely!)

If no-one has any major objections or queries I'll go ahead and cleanup the
code to assume that LH_BINARY_IMAGES contains a single value.


Regards,

-- 
Chris Lamb, UK                                       chris at chris-lamb.co.uk
                                                            GPG: 0x634F9A20
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/debian-live-devel/attachments/20080515/34f4738e/attachment.pgp