Bug#580984: dpkg: --root value not removed from filename inside chroot
Package: dpkg Version: 1.15.7.1 Hi, 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? Kind regards, Philipp Kern signature.asc Description: Digital signature
Bug#580984: dpkg: --root value not removed from filename inside chroot
Hi, 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. I think this feature deserves a non-regression test given how seldom it's used in daily usages by the developers. Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#580984: dpkg: --root value not removed from filename inside chroot
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
Bug#580984: dpkg: --root value not removed from filename inside chroot
On Mon, 10 May 2010, Guillem Jover wrote: 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? Nope, we could make an upload as 1.15.7.1 already transitioned to testing. 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. Right, but it should not be too difficult either. We could use debootstrap to create the chroot. We could make the usage of the chroot optional via the make variables used. $(DPKG_*) would hide the --root= and file based checks would be rewritten to have $(ROOT) prepended (it could be empty). The major problem is how to automatically install the same dpkg version in the chroot... but we could keep that step manual and just have checks to verify that both are in sync. Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
