Web lists-archives.com

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)




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