Re: ia32-libs{-tools}, multiarch, squeeze

[Roger Leigh <rleigh@codelibre.net>]

On Sun, Jul 05, 2009 at 07:00:38PM +0200, Stefano Zacchiroli wrote:
> 
> > As I see it, there are two major hurdles:
> > 
> > 1) Initial creation of the chroot.  As above, I think a simple
> >    script to integrate with the existing tools would work just fine
> >    here.
> 
> Sure, perhaps triggered when installing schroot via debconf or, even
> better to not bother "developer-type" of users, when installing a
> facade package such as "schroot-lenny" or something such.

Exactly.  Such a package can automatically debootstrap and set up
a suitable chroot environment without any hand-holding by the user.
It can even borrow all the apt settings such as sources.list from
the host.

I do like this idea.  We could provide a number of packages, both
named debian releases, perhaps also Providing stable/testing/unstable
aliases, and maybe a common package for the scripts themselves.

This should probably be packaged separately from schroot itself,
since it might require updating independently of the schroot
release cycle to work with Debian releases.

Thinking about it, such as setup is useful even for non-user applications
such as for buildd use, at least for the initial setup; automated
upgrades are less of an issue here, since the tools already take
some care of it.

> > 2) An easy way to run programs inside the chroot.  This depends upon
> >    exactly what you want to do.  Wrapper scripts or shell aliases do
> >    a good job for existing users; automatically generated desktop
> >    menu files for specific applications would also work.
> 
> ACK.
> 
> But I see a third one.
> 
> 3) How to maintain the chroot. With the chroots that I use (I've 4 of
>    them: three for cowbuilding in different suites, and a 32 bit one)
>    they always end up being out of date. I developed the habit of
>    updating them just before building on top of them. For users we
>    really need a way to update them in a semi-automated way that takes
>    care of security upgrades (at least). Maybe unattended-upgrades
>    with a specific configuration can be the way to go?

This is a very valid point.  Since it's an entire system within a
system, it does need perioding updating with apt/aptitude.  For
sbuild use, we have the general tools sbuild-update/sbuild-upgrade
etc. which are just thin wrappers around
"schroot -c $chroot -u root -- apt-get update" etc.  But they still
need running by hand or via a cron job (or for sbuild use, they can
be triggered to run before a build).

I don't have a good answer for how this should be handled for normal
users.  Currently they would need to do this by hand or via a wrapper
to make it simpler.  Something along the lines of unattended-upgrades
would be nice, driven by a cron job.  This could be provided directly
inside the "chroot containing" package the user would install.

This is one area where multiarch will vastly improve the user
experience, since it's all done on a single system.  At least for
the simple 32/64-bit system case; you'll still need virtualisation
for multiple distributions, which it won't cater for.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.