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

Martin Pitt mpitt at debian.org
Mon Aug 15 11:39:11 UTC 2016


Hello Johannes,

Johannes Schauer [2016-08-14 16:41 +0200]:
> I agree with Iain that the binaries belong into $PATH for the reasons he
> mentioned. If autopkgtest changes that, then sbuild will follow because even
> with your changes, the autopkgtest approach is still superior to other
> solutions.

These will now be in /usr/bin/autopkgtest-virt-* again (see below),
still with adt-virt-* compat symlinks. So when autopkgtest 4.0.5 gets
uploaded it'd be nice if you could update sbuild to
s/adt-virt/autopkgtest-virt/.

Please also add an autopkgtest to sbuild that exercises the -virt
backends, to prevent breaking sbuild again in the future.

Ian Jackson [2016-08-14 22:12 +0100]:
> Martin Pitt writes ("Re: Bug#833407: Please put adt-virt-* binaries back onto PATH"):
> > Of course it's possible (and not hard) to re-use them -- I mean that
> > from my perspective they were not meant to be public API,
> 
> Certainly they were so intended by me when I wrote and documented
> them.  I don't see how "they were not meant to be" and "from my
> perspetive" can be compatible, given that you were not the person who
> invented this API.

As I said: neither the package description, nor the packaging, nor
README.virtualisation-server nor the naming of those show any hint
about not just being an internal API for autopkgtest.

> A better question would be whether they _should_ be a public API.  I
> hope that Johannes and I have convinced you that the answer is that
> they should.

He didn't, but at this point I propose we agree to disagree.

> > Would you be okay with calling those from /usr/share/autopkgtest/virt/
> > for now?
> 
> I think this would be a bad change for the reasons I have explained.

With https://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=6af4947b6
they are now back in /usr/bin. It's against my better judgement, but
it's not that important after all.

> If piuparts requires the absolute path, rather than invoking it via
> execlp, then that is IMO a bug.  However, looking at piuparts in sid
> it seems that it takes a command line argument and passes it to
> Python's subprocess.Popen(,shell=True,).  And the help messages talk
> about adt-virt-*.

After the next upload I'll file a bug against piuparts to update the
help message.

> I am disappointed to see no response to the technical points I made
> about PATH, and instead simply a request to you to do it his way.

I *did* respond to those.

> I am considering referring this dispute to the TC (!)

Really -- with these two responses I'm almost inclined to revert the
above commit.. I really don't like playing this "Who feels offended
the most wins" game.

Regards,

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)



More information about the autopkgtest-devel mailing list