Re: multistrap on ubuntu
Wookey <wookey@wookware.org> writes:
> 4) Multistrap specifies the wrong path for the sources list when doing
> the initial package install if aptsources is specified. This doesn't
> actually seem to matter, but is confusing.
I think this might be http://bugs.debian.org/593561
> 5) There is a bug that multistrap tries to install packages listed in
> config stanzas which as not referenced in debootstrap=
I think that's this bit. It should have something like "next unless
$sect in @bootstrap_sections".
foreach my $sect (sort keys %packages) {
my @list = split (' ', $sect);
foreach my $pkg (@list) {
next if ($packages{$pkg} =~ /^\s*$/);
my @long=split (/ /, $packages{$sect});
foreach my $l (@long) {
chomp ($l);
if (defined $explicit_suite) {
# instruct apt to get packages from the specified
# suites (when the package exists in more than one).
$str .= " $l/$suites{$sect}" if ((defined $l) and ($l !~ /^\s*$/));
} else {
$str .= " $l" if ((defined $l) and ($l !~ /^\s*$/));
}
}
}
}
> 2) Flat URLs
>
> [...] The package/suite syntax cannot be used so I think that
> specifying package pinning would be the only way to do it.
On conventional systems with hybrid repositories (such as Grip and
Squeeze) I've always found package/suite to be an unreliable approach,
because it only affects the immediate package, and not its dependencies.
I have successfully installed a package from a flat repository using
suite=./ components= explicitsuite=false.
FWIW I am successfully using pinning with multistrap thusly:
mkdir -p target/etc/apt/preferences.d
cat >target/etc/apt/preferences.d/grip-beats-squeeze.pref <<EOF
Explanation: Prefer Emdebian to Debian.
Package: *
Pin: release l=EmdebianGrip
Pin-Priority: 550
Explanation: ...except for a kernel silly.
Package: linux-base
Pin: release l=EmdebianGrip
Pin-Priority: 500
EOF
[...]
multistrap -d target -f target/etc/multistrap.conf
> 3) Nobbling services
>
> In fact it's important to stop apps starting services, as higher-level
> services will result in things like apps in the chroot being bound to
> socket on the base system.
I think this is release-critical, or at least important.
> Apparently debootstrap has a little package that it installs and then
> removes to accomplish this. Shall I file a bug about this to keep it
> in mind?
I like the idea of doing it via a small deb, because it means that it
can be un-done simply by purging that deb.
I had a mind to simply have multistrap install debootstrap's deb,
thinking it might even be a normal .udeb distributed in the d-i part of
the archive. Unfortunately I couldn't see in debootstrap's code where
it gets the deb from; I'd appreciate insights into this.
> There may be more that should be done to safely install stuff in
> chroots?
There is indeed, at least for native builds. Looking at live-build,
transmute (my own infrastructure) and debootstrap, I find:
- The following mountpoints are temporarily mounted:
dev dev/pts dev/shm proc proc/bus/usb selinux sys tmp var/lock
var/run var/tmp
- The following files are temporarily replaced with stub versions:
bin/hostname
etc/apt/apt.conf
etc/apt/sources.list
etc/debian_chroot
etc/fstab
etc/hostname
etc/hosts
etc/kernel-img.conf
etc/mtab
etc/resolv.conf
sbin/initctl
sbin/ldconfig
sbin/start-stop-daemon
usr/bin/ldd
usr/sbin/policy-rc.d
var/lib/dpkg/available
var/lib/dpkg/status
Reply to: