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

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



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?

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

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

> > 3) How to maintain the chroot. With the chroots that I use (I've 4 of
<snip>
> 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.

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? ...

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.

Pretty cool stuff.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime

Attachment: signature.asc
Description: Digital signature


Reply to: