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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
