[buildd-tools-devel] sbuild/schroot session at debconf?

[rleigh at codelibre.net]

> I guess Roger is not going to be around to give us all some knowledge
> transfer? (e.g I find myself often wondering if something was done a
> particular way due to hard thought about security models or
> overarching design, or if it was random/unimportant, because I am
> completely ignorant of project history prior to about 2 yrs ago). It
> feels like software that has actually been designed, rather than just
> flung together, so I worry that I am making ignorant decisions that
> will spoilt that design over time...

I'm certainly available to answer questions, and I do intermittently
follow this list.  If you're ever wondering why things were done a certain
way I'm happy to help (if I remember the answer!)

Regarding the design, sbuild is certainly a bit of a mixture.  All the
tools "evolved" somewhat in their early years and when I got involved I
did various rounds of refactoring over the years to try and impose some
consistency and design, which has been constrained in some cases by the
requirement for backward compatibility and interoperability with other
tools.

schroot on the other hand is vastly cleaner, mainly because it was started
as a separarate codebase with a clean slate and some upfront and ongoing
design work, and has been kept clean by refactoring the API when new
requirements arrived, rather than jamming in new features wherever they
would fit.

A longer-term discussion you might want to have at debconf is the
direction you want to take these tools in.  When I originally wrote
schroot, it was designed with the needs of sbuild in mind as the initial
main focus, and we made it portable across all the platforms Debian
supports.  But even with schroot, we retained the old codepaths in sbuild
to support sudo, so schroot support could be dropped, or it could be
replaced with another tool entirely--the sbuild interfaces would allow
another system to be dropped in with the addition of a single class to add
support.  When I wrote schroot, there weren't any alternatives with its
featureset, but now there are several, and if you think there would be
advantages to switching/supporting additional chroot modes then it's
certainly feasible.

Just as a final note, one looming issue is #778112 (schroot gcc5 FTBFS). 
I've tried to reproduce, and I can do so as described in the report, but I
can't as a standalone testcase.  If anyone has time to try investigating
it, that would be appreciated.


Regards,
Roger