If LB_BACKPORTS=true, then backports are configured in sources.list,
however, not enabled.
If backports are enabled depends on pinning, either manually through
apt/preferences.d snipplets in local includes/chroot_apt, or,
depending on distribution (e.g. building artax-backports enables
pinning automatically).
If both bootstrap-base and live-installer are available on the installer,
live-installer is prefereded by d-i (because of the live specific .disk info).
If live-installer is included, can be disabled with live-installer/enable=false
and d-i will use bootstrap-base in order to debootstrap the base system on
/target.
If not building a derivative with two seperate repositories,
users should only need to bother about setting the
--mirror*|LB_MIRROR* options, the --parent-mirror*|LB_PARENT_MIRROR*
does get set automatically correctly now.
When there is an error, the Exit() handler unmounts filesystems within
the chroot. This adds /root/config to the list used when /proc/mounts is
not available.
This reverts part of cacf9b6e34 (but also adds a "bind" option to the
remount command, as documented in mount(8)).
Apparently, doing "mount -o bind,ro" doesn't work. It outputs:
mount: warning: chroot/root/config seems to be mounted read-write.
and mounts read-write instead of read-only. This behaviour is
documented in mount(8). Newer kernels do seem to allow
combining bind with the read-only option (see mount(2)), but this does
not seem to work (possibly because mount is trying to be smart).
Previously, the config was bindmounted inside the chroot only for hooks
from the config dir, now it is done earlier so it is available for all
hooks.
Note that it is now also done if there are no hooks, but this is
probably enough of an exception case to not warrant the extra plumbing
required to detect the case (and doing an extra bindmount shouldn't
really hurt anyway...).
lb_chroot_hooks would copy the hooks to run to
chroot/root/lb_chroot_hooks, but then try to run them from chroot/root
(which obviously fails). This means lb_chroot_hooks has not been working
for hooks from /usr/share/live/build/hooks since lb_chroot_hooks was
added in revision e4793268. Running hooks from the config directory was
unaffected.
Apparently, dash doesn't expand shell patterns within a quoted string,
whereas bash does. We can't remove the quoting entirely, though, since
that would cause problems when $LB_BASE or $_HOOK contains spaces (note
that $_HOOK can probably never contain spaces, but let's handle it just
in case). Only quoting the expansion of $LB_BASE and $_HOOK, but not the
shell pattern should make the hooks work with both bash and dash again.
