Bug#833407: Please put adt-virt-* binaries back onto PATH
josch at debian.org
Thu Aug 4 12:33:15 UTC 2016
On Thu, 4 Aug 2016 00:47:47 +0100 Ian Jackson <ijackson at chiark.greenend.org.uk> wrote:
> I see that after installing a recent autopkgtest, I no longer have
> adt-virt-schroot, adt-virt-null, etc. I would like to suggest that
> this change be reverted, for the following reasons:
> My original design intent was that:
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. 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.
> I see that 2 and half of 4 has already happened: sbuild has an
> --adt-virt-server option. sbuild expects to find the corresponding program
> on PATH.
And sbuild is now broken by this release.
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.
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
More information about the autopkgtest-devel