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

[Martin Pitt]

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)

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

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

[Johannes Schauer]

Hi,

Quoting Martin Pitt (2016-08-14 16:25:54)
> Would you be okay with calling those from /usr/share/autopkgtest/virt/ for
> now?

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.

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.

Thanks!

cheers, josch


signature.asc
Description: signature

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

[Martin Pitt]

Hello Johannes,

Johannes Schauer [2016-08-12 15:14 +0200]:
> > The adt-virt-* programs were just never advertised/packaged/documented to be
> > that,
> 
> When I put adt-virt-* support into sbuild, I did that without having consulted
> with autopkgtest maintainers. So apparently it was advertised and documented
> enough such that I not only learned about this possibility but was able to
> implement a full consumer of the functionality. So my experience here differs.

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, nor does the 
documentation or the package description express that.
So I didn't think twice to move them. Anyway, you and Ian disagree.

Would you be okay with calling those from /usr/share/autopkgtest/virt/
for now?

> > so please accept that I *was* fairly surprised to see them being used
> > externally.  codesearch has been broken for a while, so I'm not sure whether
> > anything else uses adt-virt-* right now.
> 
> I found piuparts, pbuilder, jenkins-debian-glue, pkg-perl-tools and debci.

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.

Thanks,

Martin

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


signature.asc
Description: PGP signature

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

[Johannes Schauer]

Hi Martin,

Quoting Martin Pitt (2016-08-12 14:45:29)
> I wasn't aware that something else even used them directly.  Hence the quick
> upload to put back the symlinks into /usr/bin/ as a stopgap

thanks for that.

> > 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.
> 
> Yes, agreed.

Also remember that there are more out-of-tree users than just sbuild. See
below.

> There are certainly no (relevant) reverse dependencies of autopkgtest -- in
> particular, sbuild does not even have a Suggests: for it,

Thanks for that as well. I fixed the sbuild package and will upload as soon as
your last autopkgtest upload hits the mirrors and I can test it.

> I never said that it wasn't useful, just that I *consider* a CLI as not
> really that easy/robust to use -- I said it's a lot easier to use a library.
> And if you use a CLI anyway, then using "schroot" or "lxc-attach" directly is
> not much harder but much simpler to understand than going through the
> adt-virt-* indirection.

I disagree. For me, the point of the adt-virt-* tools was to unify all the
multiple different command line interfaces that existing tools offered.
Interfacing with a running schroot, lxc or qemu instance is very different from
each other and by using adt-virt-* in sbuild, this "indirection" was an
advantage for me because it allowed me to add support for many backends without
writing the interfacing code myself. Instead, all the code to talk about these
backends lived in one place maintained outside of sbuild. Sure, adt-virt-* adds
just another layer but I think it's a useful one. For my usage, the downsides
of this indirection are far outweighed by the upside of not having to implement
this myself.

> Right. And we already have a Python binding, even though it hasn't had a
> stable API -- it hadn't been a separate Python module for a long time, and
> since its introduction the API changed several times.

If I understand it correctly, ceridwen managed to convert all of autopkgtest
into Python modules and at the same time add setuptool support (but this is a
discussion for another thread).

> Maybe/apparently there is a general usefulness of an API that abstracts away
> different virtualization backends (in the spirit of libvirt).

Yes, there is.

> The adt-virt-* programs were just never advertised/packaged/documented to be
> that,

When I put adt-virt-* support into sbuild, I did that without having consulted
with autopkgtest maintainers. So apparently it was advertised and documented
enough such that I not only learned about this possibility but was able to
implement a full consumer of the functionality. So my experience here differs.

> so please accept that I *was* fairly surprised to see them being used
> externally.  codesearch has been broken for a while, so I'm not sure whether
> anything else uses adt-virt-* right now.

I found piuparts, pbuilder, jenkins-debian-glue, pkg-perl-tools and debci.

Reprotest forked the autopkgtest code before the 4.0 release and thus doesn't
suffer from this problem.

Thanks!

cheers, josch


signature.asc
Description: signature

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

[Martin Pitt]

Hello Ian,

Ian Jackson [2016-08-12 12:06 +0100]:
> 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.

It seems to me the core of the misunderstanding is that apparently you
intended/want the adt-virt-* backends to be a first-class public
interface, whereas I have always considered them internal to
autopkgtest. These backends have never been described, packaged, or
advertised as something independent of autopkgtest, there has never
been a separate project that implemented a new one, and up to today
(when I saw the bug report from Johannes about breaking sbuild) I
wasn't aware that something else even used them directly. Hence the
quick upload to put back the symlinks into /usr/bin/ as a stopgap --
apparently the "proper" fix takes some more discussion.

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

Yes, agreed.

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

It certainly was a deliberate decision of me to take these out of
$PATH under the above perspective.(i. e. before I was aware of sbuild,
and that you intended to make the virt backends first-class external
and public interfaces). For sure it was my mistake to not check for
external users of adt-virt-*, as I have always thought of those as
internal private API. There are certainly no (relevant) reverse
dependencies of autopkgtest -- in particular, sbuild does not even
have a Suggests: for it, and all other hits in "apt-cache rdepends
autopkgtest" want the actual test tool, not the virt backends.

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

I didn't mean to insult you, sorry if I did. "Not being comfortable to
use" and "not considered a public API" is far away from "dissing" or
claiming to be "not useful".

I never said that it wasn't useful, just that I *consider* a CLI as
not really that easy/robust to use -- I said it's a lot easier to use
a library. And if you use a CLI anyway, then using "schroot" or
"lxc-attach" directly is not much harder but much simpler to
understand than going through the adt-virt-* indirection.

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

Right. And we already have a Python binding, even though it hasn't had
a stable API -- it hadn't been a separate Python module for a long
time, and since its introduction the API changed several times.

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

I didn't even propose an actual alternative design yet :-)

Maybe/apparently there is a general usefulness of an API that
abstracts away different virtualization backends (in the spirit of
libvirt). The adt-virt-* programs were just never
advertised/packaged/documented to be that, so please accept that I
*was* fairly surprised to see them being used externally. codesearch
has been broken for a while, so I'm not sure whether anything else
uses adt-virt-* right now.

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

*If* someone writes a new backend, I would much rather discuss the
design of that first indeed -- this needs more coordination than just
where to put the binary. I daresay that the chance of this actually
happening is very small anyway (it hasn't happened in more than 10
years), so this is still purely theoretical. I would like to hear a
good rationale for using a different language than the existing ones,
we would need to create conformance tests for the CLI API, and change
the packaging and documentation (it feels wrong and unclean to depend
on "autopkgtest" if you want some library for a virtualization
abstraction, which has nothing to do with what autopkgtest says on the
tin).

> It seemed to me, and it still seems to me, that the best approach for
> this is to think of the virt 

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

[Ian Jackson]

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

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

[Martin Pitt]

Hello Johannes,

Johannes Schauer [2016-08-12  9:11 +0200]:
> Are you suggesting that every consumer of the virt backends embeds Python code
> to do that?

I'm suggesting that using the Python API is much easier, *if* your
program is already written in Python or can embed Python easily [1]. If
this is not the case, then it's of course fine to use the virt backend
programs directly.

> > Both of these are only theoretical. Also, note that
> > /usr/share/autopkgtest/virt/ is only the default path, you can always
> > specify the full path to a virt server with autopkgtest(1).
> 
> Sure you can, but that makes any virt server that is for its choice of
> programming language unsuitable for /usr/share somewhat "special". I do not 
> see
> why the programming language should matter for the consumer. By making this
> move, you are artificially limiting adoption of this useful interface that
> earlier autopkgtest releases offered.

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.

> And again we have not solved the problem that everybody is implementing their
> own wrapper to vitalization environments.

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. For most projects it would be
simpler to use schroot or lxc-attach directly rather than re-writing
all the encoding, pipelining, and timeout stuff for autopkgest's virt
backends, and for most projects it does not make that much sense to
offer the full choice of supported backends. But of course YMMV and I
don't want to stop people from reusing these :-)

Martin


[1] By depending on autopkgtest you already transitively depend on
python3, so this is not a question of extra dependencies.


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


signature.asc
Description: PGP signature

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

[Johannes Schauer]

Hi Martin,

Quoting Martin Pitt (2016-08-12 08:42:02)
> As for third-party users of the backends: Using the Python API
> (adt_testbed.py) is a lot easier and more robust than talking to the
> backend servers directly, due to all the encoding/decoding, timeout
> handling, environment passing etc. -- if the goal is to avoid code
> duplication, then using the virt backends directly only goes half way.
> I don't actually want to promote and recommend using virt/* directly
> for these reasons.

I may misunderstand you, but after having read your reply to the sbuild bug
#833436 I have to ask:

Are you suggesting that every consumer of the virt backends embeds Python code
to do that? This is relatively painless for sbuild as it's written in Perl and
embedding some Python code will be ugly and inconvenient but doable. But doing
so is even less convenient in other programming languages. I thought that
exposing this functionality via call-able programs with which one can interface
via stdin/stdout was especially brilliant because it didn't impose any
restrictions on the programming language that consumers of this functionality
use. Any programming language can fork/exec and read from and write to file
handles.

> > Otherwise the out-of-tree server has to go in /usr/share/autopkgtest/virt,
> > which is not really its bailiwick.  (And what if the virt server is a
> > compiled machine executable and unsuitable for /usr/share?)
> 
> Both of these are only theoretical. Also, note that
> /usr/share/autopkgtest/virt/ is only the default path, you can always
> specify the full path to a virt server with autopkgtest(1).

Sure you can, but that makes any virt server that is for its choice of
programming language unsuitable for /usr/share somewhat "special". I do not see
why the programming language should matter for the consumer. By making this
move, you are artificially limiting adoption of this useful interface that
earlier autopkgtest releases offered. If people see drawbacks of the current
solution this might happen:

https://imgs.xkcd.com/comics/standards.png

And again we have not solved the problem that everybody is implementing their
own wrapper to vitalization environments.

Thanks!

cheers, josch


signature.asc
Description: signature

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

[Martin Pitt]

Control: tag -1 pending

Hello Johannes and Ian,

Ian Jackson [2016-08-04  0:47 +0100]:
> 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:
> [...]

These are valid reasons for keeping the virt runners as separate
programs and keep the communication protocol stable. However, these do
not convince me as arguments that they have to be in $PATH. IMHO these
are not programs which *users* would run on the command line -- I
think the possible confusion of "what the heck does this do" and
cluttering tab completion etc. is worse 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.

As for third-party users of the backends: Using the Python API
(adt_testbed.py) is a lot easier and more robust than talking to the
backend servers directly, due to all the encoding/decoding, timeout
handling, environment passing etc. -- if the goal is to avoid code
duplication, then using the virt backends directly only goes half way.
I don't actually want to promote and recommend using virt/* directly
for these reasons.

> Otherwise the out-of-tree server has to go in
> /usr/share/autopkgtest/virt, which is not really its bailiwick.
> (And what if the virt server is a compiled machine executable and
> unsuitable for /usr/share?)

Both of these are only theoretical. Also, note that
/usr/share/autopkgtest/virt/ is only the default path, you can always
specify the full path to a virt server with autopkgtest(1).

> I suggest that:
>   - the virt servers should be moved back to /usr/bin/adt-virt-*

I committed
https://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=00d46b4ad3
to add backwards compat symlinks, to unbreak sbuild. Indeed I was not
aware that other things used those, sorry for the hassle!

But over time I would like to get rid of those together with the other
adt* names, and have third-party users move to the private path. But
I'll follow up to the sbuild bug about that.

>   - autopkgtest(1) should treat hyphen-less virt server names
> the same way as chroot does: prefix them with `adt-virt-'.

adt-virt* is an obsolete prefix -- it is still being tried if you
invoke autopkgtest as "adt-run", but this is legacy/backwards compat
shim only. In a private path there is little reason to prefix them
with anything.

Thanks,

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

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

[Johannes Schauer]

Hi Ian,

Quoting Ian Jackson (2016-08-04 18:20:00)
> > 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.
> 
> I think in the rest of this mail you have mistakenly started writing
> adt-run-* instead of adt-virt-* ?

indeed I meant adt-virt-*. Sorry for the confusion.

Thanks!

cheers, josch


signature.asc
Description: signature

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

[Ian Jackson]

Johannes Schauer writes ("Re: Please put adt-virt-* binaries back onto PATH"):
> 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.

Right.  That was precisely what I was trying to put an end to.

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

The former would certainly be nice.  I can see why as the maintainer
you would like the latter.

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

I think in the rest of this mail you have mistakenly started writing
adt-run-* instead of adt-virt-* ?

Upstream autopkgtest seems to be deprecating adt-run in favour of a
new command line utility autopkgtest.  But those are both the DEP-8
test runners, which not so many other people are using, and for which
a transition plan with retention of adt-run for compatibility is
promised.

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

I prefer to attribute this to misunderstanding rather than
carelessness.

I don't think it had been appreciated that the adt-virt-* interface
was intended as, and had been treated as, a public interface, for use
by many other projects.

Ian.

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

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

[Johannes Schauer]

Hi again,

On Thu, 4 Aug 2016 17:20:00 +0100 Ian Jackson  
wrote:
> Johannes Schauer writes ("Re: Please put adt-virt-* binaries back onto PATH"):
> > 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.
> 
> I prefer to attribute this to misunderstanding rather than
> carelessness.
> 
> I don't think it had been appreciated that the adt-virt-* interface
> was intended as, and had been treated as, a public interface, for use by many
> other projects.

it might just've been a misunderstanding yes. Sorry, I didn't mean to offend
anybody. I can only explain this part of my previous message being formulated
in the way it was by my current frustration about this feature having vanished.

Thanks for maintaining autopkgtest!

cheers, josch


signature.asc
Description: signature

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

[Johannes Schauer]

Hi,

On Thu, 4 Aug 2016 00:47:47 +0100 Ian Jackson  
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.

Thanks!

cheers, josch


signature.asc
Description: signature

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

[Ian Jackson]

Package: autopkgtest
Version: 4.0.2

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:

0. The autopkgtest virt server protocol is a generally useful
   protocol, both sides of which might reasonably be implemented by
   software outside of (and even unconnected with) autopkgtest.

1. Programs and packages other than autopkgtest - and even users -
   would be able to provide virt servers.  They are fairly simple to
   write (although it is somewhat easier with the the VirtSubproc
   python module).

2. Programs other than autopkgtest which could make use of the
   facilities provided by virt servers could support the adt virt
   server interface, to support a wide range of virt servers.

3. Users would be able to invoke a virt server by hand for debugging.
   (This is slightly annoying because of the url encoding, but this
   is not entirely fatal to this approach.)

4. Ultimately programs which had nothing to do with testing might
   speak the autopkgtest virt server protocol to virt servers which
   were written without testing in mind.

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.

For 1 and the other half of 4 to work, the out-of-autopkgtest-tree
virt server ought to be on PATH, too.  And autopkgtest(1) ought to
find the server there.  Otherwise the out-of-tree server has to go in
/usr/share/autopkgtest/virt, which is not really its bailiwick.  (And
what if the virt server is a compiled machine executable and unsuitable
for /usr/share?)

I suggest that:
  - the virt servers should be moved back to /usr/bin/adt-virt-*
  - autopkgtest(1) should treat hyphen-less virt server names
the same way as chroot does: prefix them with `adt-virt-'.

The latter is a slightly annoying wrinkle, because it means that it is
no longer possible to have a virt server whose name does not contain a
hyphen.  One possible response to this difficulty would be to:
  - declare in the virt server spec that all virt server names
must contain hyphens
  - specify that programs which take a virt server name should
prepend `adt-virt-' to names which do not contain a hyphen

Thanks,
Ian.

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