Hi!
On Mon, 2010-05-10 at 14:26:02 +0200, Raphael Hertzog wrote:
> On Mon, 10 May 2010, Philipp Kern wrote:
> > 1.15.7.1 seems to have a regression with relation to the handling of
> > `--root'. It chroot()s into that directory nowadays and then fails to
> > call the right maintainer script due to the root value still being
> > prepended to the filename.
> >
> > This causes the following (with `--root /mnt'):
> > cannot execute /mnt/var/lib/dpkg/info/nvidia-glx.prerm: No such file or
> > directory
> >
> > strace confirms the `chroot("/mnt")' call. Am I using this parameter
> > wrongly or did something break?
> The chroot call is there since long, however when the maintainer script is
> called, the /mnt part (instdir) should be stripped (by preexecscript) and
> for some reason it's not the case here.
>
> Can you submit a log generated with dpkg -D2 <your command> ?
>
> As a reference point, 1.15.5.6 seems to be ok according to you (info
> grabbed on IRC).
>
> Problematic commits could be 15daa22fa94d19cc059d2755e5164db1a3a62791,
> a9f8f235b90a586d99a9597fa5e7f2880ec91a98 or
> ab9482eb45e27a0b0c058a2662b28b7d3642173d. They all deal with the way
> "admindir" is used internally.
This regression was introduced with
5050748f1a6bb0c0728f8c07f9058d545c80d7e0, it's missing assigning the
path returned by preexecscript to cmd->filename. I'm testing it right
now, just to make sure. We could prepare an upload with this and the
other changes, Raphaël anything else you have pending?
> I think this feature deserves a non-regression test given how seldom it's
> used in daily usages by the developers.
That would imply adding the infrastructure to create a chroot, which
might be nice to have anyway to test dpkg w/o affecting the installed
system, but still, I'm not prepared to do this right now.
thanks,
guillem
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
