Johannes Schauer writes ("Re: Please put adt-virt-* binaries back onto PATH"):
> thanks a lot Ian for making these four points. I could not've put it
> better. I was very happy with the original autopkgtest design as it
> finally gave us a way to abstract container access in a more or less
> unified way and allowed to avoid every tool to re-implement its own
> set of container support.Right. That was precisely what I was trying to put an end to. > I was even thinking of making the > autopkgtest backend the default (and integrate it such that it would > be easier to use from the sbuild command line) and drop the custom > schroot backend in favor of the adt schroot backend and thus > decrease overall code complexity. The former would certainly be nice. I can see why as the maintainer you would like the latter. > In fact I only noticed this breakage because I wanted to add support for > adt-run-* to another tool: piuparts which already comes with lots of code > supporting the adt-run-* utilities. Now its broken. I think in the rest of this mail you have mistakenly started writing adt-run-* instead of adt-virt-* ? Upstream autopkgtest seems to be deprecating adt-run in favour of a new command line utility autopkgtest. But those are both the DEP-8 test runners, which not so many other people are using, and for which a transition plan with retention of adt-run for compatibility is promised. > Another program which is now broken is the reprotest tool which is > developed in this year's GSoC project for the reproducible builds > team. > > Other tools that made use of adt-run-* and now have reduced functionality are > pbuilder, jenkins-debian-glue, reprotest, pkg-perl-tools and debci. > > Using codesearch.debian.net it is not hard to find that others > depend on specific functionality of your software. Next time you > remove features, please consult the consumers of these features > first. I prefer to attribute this to misunderstanding rather than carelessness. I don't think it had been appreciated that the adt-virt-* interface was intended as, and had been treated as, a public interface, for use by many other projects. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
