Firstly I want to say that on the whole I am very pleased to see
autopkgtest being taken care of, and being deployed and developed.
But, now, on this question, I am upset. I designed what I thought was
a good interface, which would be flexible and extensible enough to
grow to solve a general problem.
My design approach has IMO been vindicated by the fact that there are
now out-of-tree users of this API. My design approach has also been
vindicated by the support it is now receiving from that the author of
that out-of-tree user.
I had hoped that when I explained my reasoning, it would become
apparent that my wider intent hadn't been appreciated and that this
was simply a mistake. I am very disappointed to see that I was wrong.
You wrote:
> TBH, I don't consider the autopkgtest virt backends as a generic,
> useful, and comfortable API for that -- it would need a lot of design
> work, libraries etc. to become that.
I feel insulted. You are dissing my API design. And we already have
an example - sbuild - where this was done spontaneously, demonstrating
that my API is indeed useful.
Furthermore, there is no reason why language-specific libraries
couldn't be provided (if desirable) for the making the use of the
language-neutral fork/exec interface more convenient.
In contrast, your alternative design approach doesn't seem to have
been thought through. And you do not seem to recognise the general
usefulness of a language-neutral, common API for solving this problem.
Please reconsider.
On to some details:
> I am okay with adding another lookup path: I. e. a virt backend xxx is
> searched in /usr/share/autopkgtest/virt/xxx and /usr/bin/[some prefix]-xxx
> unless it is specified with full path.
>
> But this is moot as long as there aren't actually any external
> or compiled backends.
Are you suggesting that if and when someone writes a backend in a
compiled language, they should
1. file a bug against autopkgtest to ask you to define the
right path or search strategy to use; and
2. file a bug against all users of adt virt servers to ask them
to search the new path ?
That's obviously not going to be convenient.
Also, even if there is going to be a /usr/share/autopkgtest, using
just /usr/share in this way is not correct. Callers should
presumably look in /usr/local/share/autopkgtest/virt too.
Compare /usr[/local]/share/man, /usr[/local]/lib/*.so, etc.
When I designed this interface, I didn't want everyone to have to have
their own path searching logic. Furthermore, these virt servers have
command line options which are passed through from callers (including
human users), even if (as you propose, and I deprecate) the executable
path itself is determined in some more complex way, and even if and
the executable is not very useful on its own. So these things need
manpages.
It seemed to me, and it still seems to me, that the best approach for
this is to think of the virt servers as special purpose command line
tools. PATH is littered with tools which are usually invoked by some
other program, and/or with formulaic names, and or with special
calling conventions. (fsck.*, <triplet>-ld, dh_auto_*, sg_*,
git-remote-*, pkg-config, ....)
The use of the adt-virt-* prefix avoids trampling all over the command
namespace. It seems to me that there is no downside to using the
command namespace.
In your other message you wrote:
> I think the possible confusion of "what the heck does this do" and
> cluttering tab completion etc. is worse
These problems are entirely theoretical, even ridiculous. There is no
problem with cluttering tab completion because the virt servers are
all named `adt-virt-*'.
And there is no evidence of anyone being confused by finding in
/usr/bin (or on their PATH) `strange' programs which are usually part
of the innards of something else, whose behaviour they don't
understand.
> than the slight inconvenience of calling these by full path for the
> three people in the world who need to do that once a year.
I'm shocked to hear you suggest that passing absolute paths is the
right answer. It's not a question of "three people [doing] that once
a year". If your approach is adopted, these absolute paths will
become embedded in other programs, which is extremely poor practice
(and contrary to Debian policy).
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.
