[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Decision 2 - Name and number of /live/filesystem.* on live media



Situation
---------

1. filesystem image names

filesystem images that contain the actual live system are, as of current
sid, by default stored in:

  /live/filesystem.{squashfs,ext*,...}


2. filesystem 'modules'

live-boot supports the use of multiple filesystem images that can get
layered on-top of each other, see 'modules' in man live-boot.


Change
------

1. using 'filesystem.*' seems to be a not a good choosen name for this.
   instead, using 'base.*' was suggested.

   please suggest names with a short reason, or a reason why we should
   keep 'filesystem.*'.


2. should we use multiple squashfs images by default, e.g. store
   the standard system in 'standard.squashfs' and all the rest in
   an additional image? if so, what name for the 'additional' image?

2.1 official images

for the official prebuilt images, we could do:

  /live/standard.squashfs
  /live/rescue.squashfs
  /live/gnome-desktop.squashfs
  /live/kde-desktop.squashfs
  /live/lxde-desktop.squashfs
  /live/xfce-desktop.squashfs

advantages:

  * read-write live media be 'upgradeable' easily: a user with a
    big enough live medium can, rather than re-download and
    re-write an entirely new image, just download the partial
    squashfs and put it on his stick and change by that the
    desktop.

  * a current debian release is about 46GB of size. moving to
    partial squashfs images would safe about 180MB
    standard.squashfs) for every non-standard squashfs image in
    webboot, bringing the mirror size down to 46GB-(5*180MB)= ~45GB

  * will allow to have a simple way of keeping all (or at least more
    than one) of our prebuilt systems in one image, means, you can
    e.g. choose at boot loader what desktop should be started.

    you can do this already now, but atm you would need to build an
    single filesystem with both kde and gnome in it, which is
    suboptimal compared to having to independent (but deduplicated)
    images with either gnome or kde.

disadvantages:

  * requires some changes in live-build, but that should be simple.

  * requires some changes in live-boot to make fetch= work with
    a list of more than one filesystem to fetch at a time, should
    be simple too.

2.2 custom images

for custom images that live-build users build (means, anything that is
not base of config-*.git from live.debian.net/gitweb), we could either
use 'custom.squashfs' for the additional squashfs with contents beyond
standard.squashfs, or, we could not build with multiple squashfs images
at all and keep only one squashfs image.


3. implementation in live-build

if multiple squashfs images, i suggest we would do it like that:

  * 1x base.squashfs: would contain what debootstrap bootstrapped

  * multiple $foo.squashfs

where $foo is replaced with the name of the package list deduced from
the filename of config/package-lists/*.{chroot.,}list (without the
.chroot.list or .list suffix):

  * putting package selections based on priority with e.g. '! Packages
    Priority standard' as in our prebuilt images in config/package-
    lists/standard.chroot.list would then produce a standard.squashfs
    on top of base.squashfs

  * having the individual tasks like e.g. 'task-gnome-desktop' in
    config/package-lists/gnome-desktop.chroot.list would produce
    task-specific partial squashfs images.

the package lists would be processed alphabetically, so people would
prefix them with numbers in the order they want.

does that sound reasonable/useful?

the only thing negative with this is that it's might going to be a
support burden to make people aware that partial squashfs images need to
match to each other. e.g. using wheezy base.squashfs with jessie
gnome-desktop.squashfs might not necessarily work and there's some
potential for mixing things up when not paying attention (we could put
some build IDs into the images and check for that, but sounds like
overengineered).

-- 
Address:        Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:          daniel.baumann@progress-technologies.net
Internet:       http://people.progress-technologies.net/~daniel.baumann/


Reply to: