Wookey <[email protected]> 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
