[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#231015: libm.so: symlink should be relative

At Fri, 12 Mar 2004 09:35:48 -0500,
Jeff Bailey wrote:
> On Fri, 2004-03-12 at 05:35, GOTO Masanori wrote:
> > > But it seems debian glibc package debian/compat=4, and
> > > rules.d/debhelper.ml has "dh_link -p$(curpass)".  Maybe package has
> > > bug in rules.
> > 
> > This is not dh_link issue.  We don't use libc6-dev.link for
> > /usr/lib/libm.so because "../../libm.so" is generated during glibc
> > build, and we put them to /usr/lib directly.
> But we call dh_link anyway for that package.  According to the man page,
> it really ought to take care of it for us.

I checked dh_link, and found that it's dh_link bug.  dh_link checks
whether target directory and top directory is same or not, but it does
not resolve all pathname.  In this case, dh_link recognizes
../../lib/libm.so.6 as


And dh_link thought this top directory is "usr".  Then dh_link use
../../lib/libm.so.6.  At least for this case, the below patch works
for me:

--- dh_link	2004-03-12 18:49:27.000000000 +0900
+++ dh_link.new	2004-03-14 12:29:37.000000000 +0900
@@ -9,6 +9,7 @@
 use strict;
 use File::Find;
 use Debian::Debhelper::Dh_Lib;
+use Cwd 'abs_path';
 =head1 SYNOPSIS
@@ -128,6 +129,9 @@
 		my $dest=pop @links;
 		my $src=pop @links;
+		# Resolve src pathname to absolute
+		$src=abs_path($src);
 		# Relavatize src and dest.

Joey, please look at this patch.  How to test in libc6-dev as following:

	> ln -sf ../../lib/libm.so debian/libc6-dev/usr/lib/libm.so ; ls -l debian/libc6-dev/usr/lib/libm.so
	lrwxrwxrwx    1 gotom    gotom          17 2004-03-14 12:26 debian/libc6-dev/usr/lib/libm.so -> ../../lib/libm.so
	> dh_link.new -plibc6-dev ; ls -l debian/libc6-dev/usr/lib/libm.so
	lrwxrwxrwx    1 gotom    gotom          18 2004-03-14 12:26 debian/libc6-dev/usr/lib/libm.so -> /lib/libm-2.3.2.so

> > In addition, I think it's good idea to put general program which
> > resolves from relative path to absolute path like "BSD readlink -f".
> > Unfortunatelly GNU readlink -f returns ENOENT if the real path is not
> > existed, and "realpath -s" returns the same path.
> I don't have my posix handy - is GNU readlink buggy?

Manpage in BSD readlink says that it cares even unexisted path.
However GNU readlink -f does not say about unexisted path - and it
returns ENOENT if the target file is not existed.  So I thought it's
cultural difference, but it may be bug.  In past debianutils had
OpenBSD's readlink, and it worked well.

-- gotom

Reply to: