On 22.05.2017 16:25, James Clarke wrote: > You say that, but this is incredibly biased. Even he admits that in the > colour choice. Disclaimer: as the cowbuilder maintainer (which comes > from the cow*dancer* source package, for historical reasons, despite > what the diagram may tell you) I am of course also biased. But I notice > that for the sbuild path, schroot is completely missing, which is > implemented in C++ and therefore probably deserves a bright red colour > just like cowbuilder in his second picture (or maybe even something > worse, depending on your views of C++). Then there's the extremely > unhelfpul, hostile comment at the end: schroot is in theory just a tool in the toolbox, even if it came from the same developer. The same is in theory true for cowdancer, but it inherently requires cooperation from the chroot as well. At the same time it won't properly work for programs that do not use the C library's file interface (e.g. if they use syscalls directly like Go). So cowdancer is in a way a very cute hack of which you might need to know the semantics whereas schroot aimed to be a fancy chroot done right. The aim of one tool was to speed-up the build (hence cowdancer and cowbuilder being built from the same source) and of the other other to get a chroot tool that can be used by unpriviledged users, in a way that allows reuse of chroot templates. I somewhat doubt that you end up hacking on a C++ setuid binary as part of Debian packaging work. And the same is likely true for cowdancer itself - although it's theoretically more brittle - with the twist that for some reason pbuilder does not have native support for it. Kind regards Philipp Kern
Attachment:
signature.asc
Description: OpenPGP digital signature