gnash-commit
[Top][All Lists]
Advanced

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

Re: [Gnash-commit] [SCM] Gnash branch, master, updated. release_0_8_9_st


From: strk
Subject: Re: [Gnash-commit] [SCM] Gnash branch, master, updated. release_0_8_9_start-66-g17d5a9b
Date: Tue, 15 Feb 2011 14:58:11 +0100

On Tue, Feb 15, 2011 at 02:21:32PM +0100, Gabriele Giacone wrote:
> On 02/15/2011 08:33 AM, strk wrote:
> >>      else
> >> -      if test -d ${KDE4_PREFIX}/lib64; then
> >> +      if test -d ${KDE4_PREFIX}/lib64 -a ! -h ${KDE4_PREFIX}/lib64; then
> >>          KDE4_PLUGINDIR="${KDE4_PREFIX}/lib64/kde4"
> >>        else
> >>          KDE4_PLUGINDIR="${KDE4_PREFIX}/lib/kde4"
> >>        fi
> >>      fi
> > 
> > This is suspicious.
> > You do strong checking against lib64/kde4
> > and no checking at all for lib/kde4 ...
> > 
> > What if lib64/kde4 is the only existing one, symlinking who knows where ?
> 
> On Debian *-amd64 archs, /lib64 and /usr/lib64 are just symlinks to /lib
> and /usr/lib which are the same real path on all archs.
> 
> 0aecfe8e43 broke debian packaging on *amd64 by considering /usr/lib64 as
> good. This fix makes build ignore such dir if it's a link.

I don't understand the rationale for preferring one over the other.

I think the original patch was meant to fix a case in which gnash
was blinldy pointing  at lib/kde4, where such directory didn't exist.

No, I don't think the original patch was good either, as rather
than checking for existance of lib/kde4 it introduced checking for
existance of lib64/kde4, and used that, if present.

What the code is still missing is a check for the directory that
will finally be used. It is done for lib64/kde4 but _not_ for lib/kde4.

--strk;



reply via email to

[Prev in Thread] Current Thread [Next in Thread]