Hello,

I'm trying to find out the chroot directory of a particular session
(for autopkgtest's schroot runner, FTR), but this doesn't work:

| $ schroot -b -c sid
| sid-amd64-327bb347-fe31-4c6d-9e36-a90ae70c4fa2
|
| $ schroot --location -n sid-amd64-327bb347-fe31-4c6d-9e36-a90ae70c4fa2
| E: --session-name is not permitted for the specified action
| I: Run “schroot --help” to list usage example and all available options
|
| $ schroot --location -c sid-amd64-327bb347-fe31-4c6d-9e36-a90ae70c4fa2
| E: sid-amd64-327bb347-fe31-4c6d-9e36-a90ae70c4fa2: Chroot not found

As a workaround I'm using --all-sessions and grep for the line with
the session ID, but that's a bit cumbersome:

| $ schroot --location --all-sessions
| /var/lib/schroot/mount/sid-amd64-327bb347-fe31-4c6d-9e36-a90ae70c4fa2

This happens with both type=directory and an union-type, as well as
with type=file.

Thanks for considering,

Martin

Might be a namespace issue.  Does adding a "session:" prefix help?
It might be defaulting to a "chroot:" prefix for this command, in
which case it can't find a session ID since it's not under that
prefix.
existed for compatibility with dchroot.  However, the existing
behaviour is suboptimal.  It only really makes sense for it to
work with one chroot at a time since the output makes little
sense otherwise.  And it only really makes sense for sessions
since there might not even be a location for some chroot
types (snapshots, block devices, loopback mounts etc.)

I'd suggest:
- making it work with a mandatory --chroot=$name parameter
- defaulting the prefix to session (for the -c arg above)
- maybe remove support for working with non-session
  prefixes entirely.  This doesn't work consistently with
  chroot/source prefixes, but it does work with sessions
  (both from chroots and source chroots).

Due to the behaviour break, I'm reluctant to change it for
1.6.x, but for 1.7.x it's a reasonable break for a new
major release.


Regards,
Roger