[Reproducible-commits] [blog] 01/01: First part of week 6 report

[Ceridwen]

This is an automated email from the git hooks/post-receive script.

ceridwen-guest pushed a commit to branch master
in repository blog.

commit 1e611a801aa62cc349e4bc03646fd0bada78b277
Author: Ceridwen <ceridwenv at gmail.com>
Date:   Fri Jul 1 09:50:58 2016 -0400

    First part of week 6 report
---
 drafts/people/ceridwen/reprotest_week6.mdwn | 63 +++++++++++++++++++++++++++++
 1 file changed, 63 insertions(+)

diff --git a/drafts/people/ceridwen/reprotest_week6.mdwn b/drafts/people/ceridwen/reprotest_week6.mdwn
new file mode 100644
index 0000000..23fa12f
--- /dev/null
+++ b/drafts/people/ceridwen/reprotest_week6.mdwn
@@ -0,0 +1,63 @@
+[[!meta title="Managing container and environment state"]]
+[[!meta date=""]]
+[[!tag reproducible_builds Debian reprotest Outreachy]]
+Author: ceridwen
+
+I got another reply from Martin Pitt, I hope I'm not trying his
+patience too much.  It's clear that he has a very different mental
+model of how this should work than I did.  I'll illustrate by
+borrowing my previous example.  I know that schroot has the following
+behavior:
+
+> The default behaviour is as follows (all directory paths are inside
+> the chroot).  A login shell is run in the current working directory.
+> If this is not available, it will try $HOME (when
+> --preserve-environment is used), then the user's home directory, and
+> / inside the chroot in turn.  A command is always run in the current
+> working directory inside the chroot.  If none of the directories are
+> available, schroot will exit with an error status.
+
+I was naively thinking that the way autopkgtest would work is that it
+would set the current working directory of the schroot call and the
+ensuing `subprocess` call would thus take place in that directory
+inside the schroot.  That is *not* how it works.  If you want to
+change directories inside the virtual server, you have to use `cd`.
+The same is true of, at least, environment variables, which have their
+own specific handling in the `adt_testbed.Testbed` methods but have to
+be passed as strings, and umask.  I'm assuming this is because the
+direct methods with qemu images or LXC containers don't work.
+
+What this means is that I was thinking about the problem the wrong
+way: what reprotest needs to do is generate shell scripts.  This is
+how autopkgtest
+[works](https://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/runner/autopkgtest#n257).
+If this goes beyond laying out commands linearly one after another,
+for instance if it demands conditionals or other nested constructs,
+the right way to do it is to build an abstract syntax tree
+representation of the shell script and then convert it to code.
+
+Whether I need more complicated shell scripts depends on my approach
+to handling state in the containers.  First, I need to figure out what
+state-handling needs to be embedded *in* the shell scripts rather than
+executed from the outside.  For this, I need to know what state
+persists across separate command executions: if I call
+`adt_testbed.Testbed.execute()` twice, what if any changes I make to
+the container will carry forward from the first to the second?  This
+ought to be a documented part of adt_testbed's interface but I can't
+find any documentation to this effect.  Do you know enough about the
+containers to tell me what you would think would carry over?  (This at
+least gives me a starting point for testing the adt_testbed
+code—without documentation, I'm going to have to
+reverse-engineer it.)  For state that carries over from one command to
+another, I can control the state-handling from the Python code,
+similar to how the rebuild.sh script uses pbuilder/cowbuilder hooks to
+manage state.  Any state that doesn't carry over must be controlled
+inside the shell scripts themselves.  There is an additional advantage
+to embedding state handling in the shell scripts: I won't have to
+rewrite autopkgtest's error handling, because the reversion code will
+be executed inside autopkgtest's error handling.  Note that
+autopkgtest has a very different approach, depending on builtin
+reversion capabilities from some of its containers, but I would like
+to avoid doing the same, partly because I'm unsure if some of the
+modifications that I need to make can be reverted by the containers,
+like creating new users or mounting disorderfs.

-- 
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/reproducible/blog.git