Bug#833407: Please put adt-virt-* binaries back onto PATH [and 1 more messages]

[Ian Jackson]

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.

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.

(If we're going to go into historical questions, for example, in
autopkgtest 2.2.2, autopkgtest-xenlvm.deb had this description:

  Machinery for setting up a Xen domain which can be resumed over and
  over again, discarding changes made each time.  This can be useful
  for automated testing and other advanced techniques; autopkgtest is
  able to make use of this machinery for its virtualisation needs.
  .
  You will need a working Xen setup to make use of this software.  Your
  network administrator will need to provide support for the testbeds'
  networking requirements.  See the README for documentation.

I'm pretty sure I had conversations with people where I mentioned this
new interface, and encouraged people to use it, but I can't find now
any reccords of such emails or other conversations.)

> 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.

> piuparts does not make any assumptions about the virt server location
> or name, it's passed in full as a command line option. The others use
> autopkgtest/adt-run, not adt-virt*. So piuparts is only marginally
> affected, the others not at 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-*.

Johannes Schauer writes ("Re: Bug#833407: Please put adt-virt-* binaries back onto PATH"):
> I agree with Iain that the binaries belong into $PATH for the reasons he
> mentioned.

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 will though re-evaluate whether it makes sense for sbuild to
> change to autopkgtest as its default backend. If the adt-virt-*
> mechanism is not treated as public API then it's probably best not
> to depend on it and instead keep the backend implementations in
> sbuild itself.

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

Ian.

-- 
Ian Jackson <ijackson at 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.