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

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



At Thu, 12 Feb 2004 10:13:59 +0900,
GOTO Masanori wrote:
> At Fri, 6 Feb 2004 13:48:33 -0500,
> Joey Hess wrote:
> > Jeff Bailey wrote:
> > > Hrm..  I'd like to ask the debhelper maintainer what he thinks first -
> > > It seems to me that one of the fixups scripts (possibly dh_fixperms)
> > > should have this built in.
> > > 
> > > I'm going to be late to work today, but I'll try to remember to ask
> > > joeyh when he hops on later.
> > 
> > In debhelper v4 mode, dh_link does scan for existing non-policy
> > compliant symlinks, and corrects them.
> 
> That's nice.
> 
> 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.

So I think this bug is no relation to debhelper handling.  I would
like to put the script which I proposed and that changes ../../lib ->
/lib.  OK?


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.

Regards,
-- gotom



Reply to: