On Sun, Jul 05, 2009 at 09:06:13PM +0200, Stefano Zacchiroli wrote:
> On Sun, Jul 05, 2009 at 06:29:30PM +0100, Roger Leigh wrote:
> > 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.
>
> Yep, but not directly, because you'll need to mangle distro settings
> and stuff like that. Also, if you initialize APT settings the first
> time you create the chroots from the base system, people might then
> expect them to be kept synchronized in the future. What about copying
> them into the chroot by default as, IIUC, schroot can do for other
> files?
That's certainly a possibility. We can extend it to do whatever we
like during the setup stage, so a dedicated script to copy over the
current APT settings is easy. However, this could also break quite
easily if the user adds lots of custom stuff like local files that
aren't available in the chroot.
If the geo-ip mirror stuff is now working reliably, this means we
always have a good default to use which the user can then customise
if required. Or if debconf has the chosen country mirror stored from
installation, we just default to using that.
> > 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.
>
> It starts to get exciting :)
> BTW, do you want a bug report about this against schroot?
Yes please! Since I have the memory of a goldfish, I can't forget
this way ;)
> > 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.
>
> I cannot agree more. I use a plethora of chroots for package
> buildings, but I know various DDs which are not (yet) using stuff like
> cowbuilder due to the ignorance about schroot and similar helper
> tools. Having the packages we are discussing easy to use out of the
> box can terribly help in spreading good package building culture.
Absolutely. This is one area I've worked on quite a bit with tools
like sbuild-createchroot. While this automates what was once quite
arcane and fiddly, it still doesn't tackle the ongoing maintenance
(see below).
> > > 3) How to maintain the chroot. With the chroots that I use (I've 4 of
> <snip>
> > 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.
>
> I do that by hand for my chroots and I don't even have a wrapper
> script, probably because my number of chroots (4) is still low. Having
> a couple of wrappers schroot-{update,upgrade,...} would be more than
> enough, if they by default run on *all* chroots registered within
> schroot configuration. How does that sound? ...
You can already do this to a certain extent /without/ wrappers, for
example something like
schroot --all-chroots --user=root -- sh -c '[ -x $(which apt-get) ] &&
apt-get update && apt-get -y upgrade'
But, we can't guarantee that all chroots are Debian chroots or that
automatic maintenance is required. I think that we should either
1) Have a file inside the chroot indicating that automated unattended
upgrades are OK, or
2) Have an option in the configuration file, such as
unattended-upgrades=true
which the initial chroot setup can enable, and updating tools can
query for (schroot itself will just ignore/preserve it).
One other issue that casual users won't need to care about are the
different types of chroots schroot uses:
source <- chroot -> sessions (possibly cloned)
Some chroots can be cloned (LVM snapshots and coming very soon
[merged over the weekend] filesystem unions), and these have a
corresponding "source" chroot (the original filesystem) to allow
for updating, since updating the clone would need doing repeatedly
for each new clone. The interface doesn't yet allow for running an
update command in all source chroots, but once that's added it will
allow for easy bulk management of all chroots.
The sbuild update and creation code is actually all in a Perl module
(libsbuild-perl), and we can make this even more generic for use
outside sbuild. However, the reason most of this code exists is
because it's not currently possible to call the schroot C++ library
interface directly from Perl. If anyone has experience of using SWIG
to wrap a C++ interface for use in Perl, please get in touch. A
Perl binding to schroot would be absolutely awesome, but I lack the
expertise with SWIG to know how to get started.
> I notice just now that schroot already supports
> /etc/schroot/chroot.d/, so the additional chroot instance packages can
> just drop entries there and have the wrapper scripts work on them out
> of the box.
That would be the ideal, yes. There is a slight restriction that
chroot names can't be duplicated, so if you drop a chroot in there
that has the same name as an existing one, schroot will moan until
you rename one. But that's always been a deliberate design feature;
we would just need to ensure the packages don't use the same names.
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
