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

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



On Sun, Jul 05, 2009 at 10:41:10PM +0100, Roger Leigh wrote:
> > 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 ;)

Done: #535943. I've tried to summarize the relevant points of this
design discussion; please add whatever I might have forgot.

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

In essence, it looks like my "all" above needs to be refined. What we
need is a way for the user to declare which chroots she wants to be
automatically handled by wrapper by default. That can be, for
instance, configured using keywords in schroot.conf entries(?). Also,
I guess, a way to invoke the wrapper on specific instances given on
the command line would be nice.

Notice that the assumption that all handled chroot should be "Debian"
is probably unsound. For instance, I can imagine an interest in having
Ubuntu, or other derivatives, chroots on my machine.

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

Right. That should be handled transparently by the wrapper. On chroots
having source equivalent, the upgrade should be done there. FWIW, this
answer an (unasked) question of mine, namely: can the wrapper be
simply developed on top of another wrapper which simply execute
commands in a given chroot? The answer is "no", cause we know upgrades
should be done in source chroots.

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

Sorry, not here :-/

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

Well, while I guess that most of us already have chroots called "sid",
"lenny", and so on, we can go for "sid-instance" or something such to
distinguish legacy (i.e., packaged) chroots from the othere.

Thanks for this intriguing discussion,
Cheers.

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