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
usr/lib/../../lib/libm.so.6
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.
$src=~s:^/::;
$dest=~s:^/::;
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.
Regards,
-- gotom
Reply to: