Re: [lmi] Creating a chroot for cross-building lmi

[Greg Chicares]

On 2016-09-25 23:57, Vadim Zeitlin wrote:
> On Sun, 25 Sep 2016 21:20:55 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Here's the relevant section from the unfiltered log:
> GC> 
> GC> Selecting previously unselected package libpulse0:amd64.
> GC> Preparing to unpack .../libpulse0_5.0-13_amd64.deb ...
> GC> Unpacking libpulse0:amd64 (5.0-13) ...
> GC> dpkg: error processing archive 
> /var/cache/apt/archives/libpulse0_5.0-13_amd64.deb (--unpack):
> GC>  trying to overwrite shared '/etc/pulse/client.conf', which is different 
> from other instances of package libpulse0:amd64
> GC> dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
> 
>  FWIW, and in spite of your compliments to my Unix/Linux knowledge, I have
> no idea what happened here. The only times when I had seen a similar error
> was when I transitioned an existing Debian system from i386 architecture to
> amd64 (and yes, this can be done even though reinstalling the system from
> scratch in 64 bits might still be a better alternative). Then I was getting
> similar errors when reinstalling 64 bit packages after removing, but not
> purging (as I did want to keep their configuration) old 32 bit packages.
> And the only matches for this error I'm getting from Google also point to
> some multiarch problems. But if you hadn't used a 32 bit architecture
> before, I really don't see why would this error occur...

Ah, but the very first thing I do after debootstrap is enter a newly-
created chroot as root and run:

# Add i386 before installing wine, so that wine can run 32-bit .exe's .
dpkg --add-architecture i386

so that might explain it.

> GC> I also cherish the notion that a chroot is a completely self-contained
> GC> same-OS VM with no overhead, but now I see it isn't (though a "plain"
> GC> schroot comes pretty close).
> 
>  Yes, it does, and I use it like this too (e.g. to try the latest versions
> of everything from sid or even experimental without sacrificing my main
> system), but perhaps in this case it would be actually better to use a
> container-based solution for real isolation. Arguably, it would take you
> less time than fighting with [s]chroot and would be more useful going
> forward.

Perhaps--but OTOH I have schroot working well enough now.