Bug#833407: Please put adt-virt-* binaries back onto PATH

[Johannes Schauer]

Hi Martin,

Quoting Martin Pitt (2016-08-12 14:45:29)
> I wasn't aware that something else even used them directly.  Hence the quick
> upload to put back the symlinks into /usr/bin/ as a stopgap

thanks for that.

> > My design approach has IMO been vindicated by the fact that there are now
> > out-of-tree users of this API.  My design approach has also been vindicated
> > by the support it is now receiving from that the author of that out-of-tree
> > user.
> 
> Yes, agreed.

Also remember that there are more out-of-tree users than just sbuild. See
below.

> There are certainly no (relevant) reverse dependencies of autopkgtest -- in
> particular, sbuild does not even have a Suggests: for it,

Thanks for that as well. I fixed the sbuild package and will upload as soon as
your last autopkgtest upload hits the mirrors and I can test it.

> I never said that it wasn't useful, just that I *consider* a CLI as not
> really that easy/robust to use -- I said it's a lot easier to use a library.
> And if you use a CLI anyway, then using "schroot" or "lxc-attach" directly is
> not much harder but much simpler to understand than going through the
> adt-virt-* indirection.

I disagree. For me, the point of the adt-virt-* tools was to unify all the
multiple different command line interfaces that existing tools offered.
Interfacing with a running schroot, lxc or qemu instance is very different from
each other and by using adt-virt-* in sbuild, this "indirection" was an
advantage for me because it allowed me to add support for many backends without
writing the interfacing code myself. Instead, all the code to talk about these
backends lived in one place maintained outside of sbuild. Sure, adt-virt-* adds
just another layer but I think it's a useful one. For my usage, the downsides
of this indirection are far outweighed by the upside of not having to implement
this myself.

> Right. And we already have a Python binding, even though it hasn't had a
> stable API -- it hadn't been a separate Python module for a long time, and
> since its introduction the API changed several times.

If I understand it correctly, ceridwen managed to convert all of autopkgtest
into Python modules and at the same time add setuptool support (but this is a
discussion for another thread).

> Maybe/apparently there is a general usefulness of an API that abstracts away
> different virtualization backends (in the spirit of libvirt).

Yes, there is.

> The adt-virt-* programs were just never advertised/packaged/documented to be
> that,

When I put adt-virt-* support into sbuild, I did that without having consulted
with autopkgtest maintainers. So apparently it was advertised and documented
enough such that I not only learned about this possibility but was able to
implement a full consumer of the functionality. So my experience here differs.

> so please accept that I *was* fairly surprised to see them being used
> externally.  codesearch has been broken for a while, so I'm not sure whether
> anything else uses adt-virt-* right now.

I found piuparts, pbuilder, jenkins-debian-glue, pkg-perl-tools and debci.

Reprotest forked the autopkgtest code before the 4.0 release and thus doesn't
suffer from this problem.

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/autopkgtest-devel/attachments/20160812/29f9a5c7/attachment.sig>