Bug#374713: [Buildd-tools-devel] Bug#374713: Aborts if cd fails but seems to use pwd -P

[Christian Hammers]

Hello Roger

On 2006-06-21 Roger Leigh wrote:
> Christian Hammers <ch at debian.org> writes:
> 
> > dchroot stopped working for me. I tried schroot but it complains about
> > the same:
> >
> >   $ pwd   
> >   /home/ch
> >
> >   $ pwd -P
> >   /mnt/local/home/ch
> >
> >   $ dchroot pwd
> >   E: Could not chdir to '/mnt/local/home/ch': No such file or directory
> >   E: Session failure: Child exited abnormally with status '1'
 

> The first thing is pwd.  I'm assuming here that /home/ch is a symlink
> to /mnt/local/home/ch, or /home is a symlink to /mnt/local/home.  When
> schroot runs, it can only rely on the path as obtained with getcwd(3).

Thanks for the long explanation but the rationale why it tries to be in the
same path as before when running non-interactively is clear to me -
what I wondered is why it seems to have *changed* the behaviour regarding
the return of getcwd().
My /home/ has been a symlink to /mnt/local/home for month and until now I
started firefox in a chroot (amd64 vs i386 and flash plugin...) every day!
Only since the last update yesterday dchroot tries to cd to "pwd -P" instead
of "pwd". Why is this so?

Is dchroot *now* a symlink to schroot and has been build from a different
source in the months before? If so, what system call did the old dchroot use
to get the path as it was apparently not getcwd(3).

Surely I could change my system to use bindmounts but it maybe annoys
others, too :)

bye,

-christian-