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
signature.asc
Description: signature
