[Live-demo] 4.5alpha1 Build has started

[Hamish]

Alex wrote:
> The method I'm using closely follows:
> https://help.ubuntu.com/community/LiveCDCustomization
> 
> There is no user account, this method specifically says you
> can not have such a thing otherwise the live disc part will
> fail. Instead you put all the things you want to show up in
> the home dir into /etc/skel.
>
> When the live disc runs it will create the user and copy
> the /etc/skel into it's home dir on-the-fly.

mmph, that seems like a bit of cheap and nasty way of getting
the job done if you ask me. sucks if you want to create a second/
fresh working user account on the USB stick or VM install (which
I've been doing for sandbox purposes), but I guess I could live
with that.   comments?

 
> So yes anything that needs to be customized, xfce background,
> firefox bookmarks, symlinks can just be placed into that folder.
> To me this is a big change from the current scripts. Every
> instance of something being put on the desktop or in the home
> dir would need to be moved.

In setting up the menus etc I've tried to keep both system and
/home/user copies separate, with stuff copied into /home as
needed. I'm not too excited about abandoning that careful
separation and hours of hard work, but not sure to what extent
a bulk search and replace of /home/user/ to /etc/skel/ will
matter to that, if at all.
 
> git svn and bzr svn are exactly what I was looking at. I
> was thinking of stashing it on github or launchpad for others
> to help, but that's when I started thinking maybe we should
> just branch in svn.

I'd sort of prefer to just focus on this stabilization round
until 4.5 is out the door, seems like a bad time to start ripping
up all the floor boards in any major way. chasing moving targets
and all that.

how about this: instead of branching, just go through the scripts
and anywhere in the you see something copied to /home/user/ add
a couple of lines. the first being some grepable "#for LiveCDCustomization" comment, and the second being a clone of
the cp to /home but with the target as /etc/skel instead.
with stuff copied to both /home/user and /etc/skel both ISO
creation methods can be used without damaging the other.
so no need to branch and no need to wait either.
?

Let's see.. in 4.0rc9 /home/user after a fresh boot contains
1.4mb after login. I don't mind duplicating that.

note gvSIG, AtlasStyler, gpsdrive should install base files to
/usr/local/share/data/ and symlink, not /home directly. but they
are all just 200 kb or so, so maybe not worth worrying about.


The 'live-helper' build method (see wiki.debian.org) gives you
a bit more control. there are chances to do run scripts and 
install things both before and after the chroot.
see
 https://svn.osgeo.org/osgeo/livedvd/live-helper/trunk/README.txt

but hopefully the ubuntu method isn't too ugly. migrating to
live-helper would be a major effort, although arguably cleaner
once you're done. a downside is the install scripts couldn't be
reused independently with only minor changes as they can be now.


> though not sure what the difference between schroot,
> dchroot and chroot is.

see 'apt-cache show dchroot':
"""
Description: Execute commands in a chroot environment
 dchroot allows users to execute commands or interactive shells in
 different chroots.  A typical installation might provide 'stable',
 'testing' and 'unstable' chroots.  Users can move between chroots as
 necessary.
 .
 NOTE: the schroot package provides a better implementation of
 dchroot.  In particular:
  * dchroot quoting issues are not present.  dchroot runs commands in
    the chroot with -c option of the user's default shell; when
    multiple command options are used, the options are concatenated
    together, separated by spaces.  This concatenation breaks shell
    quoting.
  * schroot implements fine-grained access controls based on users
    and groups, either of which may be granted the ability to gain
    root access to the chroot if required.
 Using schroot will avoid these issues, as well as provide additional
 functionality dchroot does not possess.
"""


Hamish