Bug#534565: debhelper: dh_install does not properly handle dangling symlinks
On Tue, 2009-06-30 at 08:32:52 +0200, Guillem Jover wrote: > Anyway I'm attaching a fake package which has 4 test cases runable > via debian/rules, test-a, test-b and test-c fail, test-d and test-e > succeed. Bah, attached an old version, new one here. regards, guillem test-rootdir.tgz Description: GNU Unix tar archive
Bug#534565: debhelper: dh_install does not properly handle dangling symlinks
On Sun, 2009-06-28 at 16:23:10 -0400, Joey Hess wrote: > Guillem Jover wrote: > > On dh_install, when using compat level >= 7, passing an absolute path > > (like “$(CURDIR)/debian/tmp”) to --sourcedir, the first result of the > > glob is a dangling symlink (like when it points to another directory, > > which then makes it need to be an absolute path, for example > > “debian/tmp/usr/lib/libfoo.so” pointing to “/lib/libfoo.so.1”), the > > automatic fallback to look into “debian/tmp” makes the destination > > path end up in something like “/debian/tmp/”. > > I have not quite managed to comprehand what you're saying above. Perhaps > you could provide a simple example I can run? Sorry, rereading it does not seem to parse as I wanted. Let's try again, the root cause is that when you use an argument in --sourcedir that makes the glob match the filenames from foo.install but is not equal to ‘debian/tmp’, and the first result of that glob is a dangling symlink then the destination package path ends up including ‘debian/tmp’. The problematic code is around '# Fall back to looking in debian/tmp.' and '# Guess at destination directory.' Anyway I'm attaching a fake package which has 4 test cases runable via debian/rules, test-a, test-b and test-c fail, test-d and test-e succeed. Additionally other programs in debhelper handles similar dangling symlink cases correctly. > > Arguably this can be fixed by just dropping the --sourcedir > > argument, but still, it breaks the packages pretty badly, thus the > > serious severity. > > Are you saying that you filed a serious severity bug report on debhelper > because you used it in a way that failed to build some packages? That > sounds like severity inflation. I've been using --sourcedir=$(CURDIR)/debian/tmp on several of my packages for a long time, and others do as well. If then by just bumping the compat level to 7 and using what seems like a valid argument, the packages ends up being broken, that seems severe to me. But as I've tracked it down now, and worked it around, I don't care that much, feel free to downgrade if you disagree. regards, guillem test-rootdir.tgz Description: GNU Unix tar archive
Bug#534565: debhelper: dh_install does not properly handle dangling symlinks
Guillem Jover wrote: > On dh_install, when using compat level >= 7, passing an absolute path > (like “$(CURDIR)/debian/tmp”) to --sourcedir, the first result of the > glob is a dangling symlink (like when it points to another directory, > which then makes it need to be an absolute path, for example > “debian/tmp/usr/lib/libfoo.so” pointing to “/lib/libfoo.so.1”), the > automatic fallback to look into “debian/tmp” makes the destination > path end up in something like “/debian/tmp/”. I have not quite managed to comprehand what you're saying above. Perhaps you could provide a simple example I can run? > Arguably this can be fixed by just dropping the --sourcedir > argument, but still, it breaks the packages pretty badly, thus the > serious severity. Are you saying that you filed a serious severity bug report on debhelper because you used it in a way that failed to build some packages? That sounds like severity inflation. -- see shy jo signature.asc Description: Digital signature
Bug#534565: debhelper: dh_install does not properly handle dangling symlinks
Package: debhelper
Version: 7.2.16
Severity: serious
Hi!
On dh_install, when using compat level >= 7, passing an absolute path
(like “$(CURDIR)/debian/tmp”) to --sourcedir, the first result of the
glob is a dangling symlink (like when it points to another directory,
which then makes it need to be an absolute path, for example
“debian/tmp/usr/lib/libfoo.so” pointing to “/lib/libfoo.so.1”), the
automatic fallback to look into “debian/tmp” makes the destination
path end up in something like “/debian/tmp/”.
Arguably this can be fixed by just dropping the --sourcedir
argument, but still, it breaks the packages pretty badly, thus the
serious severity.
I didn't notice this on few of my packages (libpmount, libaio, etc) on
my build system because I've the shared library packages installed,
which makes the absolute symlinks not be dangling ones.
Attached patch should fix this.
regards,
guillem
diff --git a/dh_install b/dh_install
index 5a3a7f5..3aa748a 100755
--- a/dh_install
+++ b/dh_install
@@ -153,7 +153,7 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
my @found = glob "$srcdir/$glob";
if (! compat(6)) {
# Fall back to looking in debian/tmp.
-if (! @found || ! -e $found[0]) {
+if (! @found || ! (-e $found[0] || -l $found[0])) {
@found = glob "debian/tmp/$glob";
}
}
