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