[buildd-tools-devel] Bug#633671: Bug#633671: Bug#633671: schroot behaves differently depending on cwd

[Roger Leigh]

tags 63367 + fixed-upstream pending
thanks

On Tue, Jul 12, 2011 at 11:08:13PM +0200, Thibaut VARENE wrote:
> On Tue, Jul 12, 2011 at 10:43 PM, Roger Leigh <rleigh at codelibre.net> wrote:
> > On Tue, Jul 12, 2011 at 09:50:22PM +0200, Thibaut VARENE wrote:
> >> On Tue, Jul 12, 2011 at 9:33 PM, Roger Leigh <rleigh at codelibre.net> wrote:
> >>
> >> > The reason we don't implement a fallback is because it would make
> >> > the behaviour unpredictable.  The exact logic is as follows:
> >>
> >> OK. I'm not entirely sure I see how it would be unpredictable, and
> >> more to the point why dchroot behaves differently from schroot, but
> >> then again, I'm not very familiar with either tool.
> >
> > If we can't chdir to the specific directory, the results could be
> > both unpredictable and disastrous!  In the case of other commands
> > such as "apt-get ..." the current directory doesn't matter, but
> > there's no way for schroot to know that in advance, so we always
> > have to play it safe.
> 
> Yeah I get that.
> 
> >> The thing is that the error message isn't really explicit, when you're
> >> unaware of this "design choice"... I don't how it could be improved
> >> though.
> >
> > We could add an additional information message e.g.
> >
> > E: Failed to change to directory ‘/tmp/syscheck’: No such file or directory
> > I: Does this directory exist inside the chroot?
> > I: Use the --directory option to run the command in a different directory.
> 
> Well, the problem is that when I first saw the error message, I didn't
> realize it was talking about the chroot, but I quickly suspected it
> (it wouldn't have made /any/ sense otherwise). This clarifies the
> situation. What remains unclear to the average user unaware of the
> implications of a fallback policy for commands is /why/ the directory
> needs to be in the chroot. Put another way, at some point I started
> believing schroot wouldn't work unless the whole /home/buildd was
> loop-mounted into the chroot. I didn't realize it only need the
> specific directory it was executed from. I suppose some extra
> documentation in the manpages regarding the behaviour of schroot when
> executing shells vs commands might be helpful to clarify this.

I've written a new section into the manual page (Directory Fallbacks)
to properly document this (attached).  Is this OK with you?


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: schroot.ps.gz
Type: application/octet-stream
Size: 59508 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20111127/864e9362/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: schroot.1.gz
Type: application/octet-stream
Size: 9448 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20111127/864e9362/attachment-0005.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dchroot.1.gz
Type: application/octet-stream
Size: 5441 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20111127/864e9362/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dchroot-dsa.1.gz
Type: application/octet-stream
Size: 4606 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20111127/864e9362/attachment-0007.obj>