Bug#231015: libm.so: symlink should be relative
- To: Joey Hess <joeyh@debian.org>
- Cc: GOTO Masanori <gotom@debian.or.jp>, 231015@bugs.debian.org
- Subject: Bug#231015: libm.so: symlink should be relative
- From: GOTO Masanori <gotom@debian.or.jp>
- Date: Tue, 13 Apr 2004 01:10:14 +0900
- Message-id: <[🔎] 81vfk5tbx5.wl@omega.webmasters.gr.jp>
- Reply-to: GOTO Masanori <gotom@debian.or.jp>, 231015@bugs.debian.org
- In-reply-to: <81wu5nxs6h.wl@omega.webmasters.gr.jp>
- References: <20040203235340.GA8336@bylbo.nowhere.earth> <81fzdq85ex.wl@omega.webmasters.gr.jp> <1075985103.1331.2.camel@outpost.dnsalias.org> <20040206184833.GA16799@kitenet.net> <81ekt16qw8.wl@omega.webmasters.gr.jp> <81ekryz721.wl@omega.webmasters.gr.jp> <1079102147.1616.3.camel@outpost.dnsalias.org> <811xnwyuhy.wl@omega.webmasters.gr.jp> <81y8q3xw5m.wl@omega.webmasters.gr.jp> <81wu5nxs6h.wl@omega.webmasters.gr.jp>
Joey,
This #231015 is critical bug - could you look at my last post (the
attached mail) ? I clone this bug and reassign it to debhelper
if you think it's dh_link bug.
Bug Summary: dh_link does not work for relative symlinks, and I make a
patch for fixing this problem.
Regards,
-- gotom
At Mon, 15 Mar 2004 02:19:18 +0900,
GOTO Masanori wrote:
>
> At Mon, 15 Mar 2004 00:53:25 +0900,
> GOTO Masanori wrote:
> > At Sun, 14 Mar 2004 12:31:37 +0900,
> > GOTO Masanori wrote:
> > > 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
> >
> > Umm, this patch has the bug. The resolved symlink path should be
> > "/lib/libm.so"...
>
> The problem is that if /lib/libm.so is existed, then this path keeps
> resolving to /lib/libm-2.3.2.so because readlink(2) resolves both
> . and .. and symlinks. So we can't use abs_path() for this purpose.
>
> I implement path expand routine which resolve . and .., but don't
> resolve symbolic links.
>
> This patch can handle to expand pathname even if the first character
> in $src component includes `..' or `.'.
>
>
> --- dh_link 2004-03-12 18:49:27.000000000 +0900
> +++ dh_link.new 2004-03-15 02:09:35.000000000 +0900
> @@ -78,6 +78,39 @@
>
> init();
>
> +# expand_path expands all path "." and ".." component, but don't
> +# resolve symbolic links.
> +sub expand_path
> +{
> + my $start = @_ ? shift : '.';
> + my @pathname = split(m:/+:,$start);
> +
> + my $entry;
> + my @respath;
> + foreach $entry (@pathname) {
> + if ($entry eq '.' || $entry eq '') {
> + # Do nothing
> + } elsif ($entry eq '..') {
> + if ($#respath == -1) {
> + # Do nothing
> + } else {
> + pop @respath;
> + }
> + } else {
> + push @respath, $entry;
> + }
> + }
> +
> + # reconstruct full pathname
> + my $result;
> + foreach $entry (@respath) {
> + $result .= '/' . $entry;
> + }
> +
> + return $result;
> +}
> +
> +
> foreach my $package (@{$dh{DOPACKAGES}}) {
> my $tmp=tmpdir($package);
> my $file=pkgfile($package,"links");
> @@ -128,6 +161,9 @@
> my $dest=pop @links;
> my $src=pop @links;
>
> + # Expand . and .. in src.
> + $src=expand_path($src);
> +
> # Relavatize src and dest.
> $src=~s:^/::;
> $dest=~s:^/::;
>
>
> > 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-15 02:11 debian/libc6-dev/usr/lib/libm.so -> ../../lib/libm.so
> > ./dh_link -plibc6-dev ; ls -l debian/libc6-dev/usr/lib/libm.so
> lrwxrwxrwx 1 gotom gotom 12 2004-03-15 02:11 debian/libc6-dev/usr/lib/libm.so -> /lib/libm.so
>
> I keep testing for another path examples.
>
> Regards,
> -- gotom
>
Reply to: