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

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
    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:


Reply to: