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

Bug#627439: handling Ubuntu's multiple manifest scheme

Package: live-build
Version: 3.0~a17-1
Severity: wishlist
User: ubuntu-devel@lists.ubuntu.com
Usertags: origin-ubuntu oneiric

I'm looking for some guidance on one of the remaining major pieces
involved in making live-build usable for official Ubuntu live filesystem

Most package installation in our current live filesystem builds is done
in two stages.  The first corresponds to the packages that should be
copied to an installed system when installing from the live CD, and the
second corresponds to the packages that may need to be removed from the
installed system: this includes live CD boot infrastructure, the
installer itself, and other bits and pieces such as language packs.  At
the end of the first stage, we write out filesystem.manifest-desktop; at
the end of the second stage, we write out filesystem.manifest.

After copying files to disk, the installer takes the set of packages in
filesystem.manifest but not in filesystem.manifest-desktop, eliminates
any packages from that set that some bit of the installer explicitly
asked to keep (for example, we might as well keep the language packs
corresponding to the user's language rather than making them reinstall
them from the network), and removes that set of packages from disk.

live-build doesn't currently support this kind of two-stage installation
except by means of local hooks, and as explained in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627332#25 I would like
to find a way to do this without local hooks.  I'm happy to do the
implementation work, but do you have any ideas on a nice way to do this
within the structure of live-build?

There is of course the possibility of not bothering with a two-stage
installation, and instead computing filesystem.manifest-desktop
independently.  I'm reluctant to take this approach because it would
carry risk of archive skew and/or simple coding errors resulting in
filesystem.manifest-desktop not matching what apt would have installed
at that point in a hypothetical two-stage installation; but it's an
option if you think this just won't fit.


Colin Watson                                       [cjwatson@ubuntu.com]

Reply to: