Flaw in print/acroread7 (was: Re: [ru@FreeBSD.org: [patch] mixed i386/amd64 ports semi-broken])

[Jean-Yves Lefort]

On Mon, 30 Jan 2006 00:58:39 -0500
Kris Kennaway <kris at obsecurity.org> wrote:

> On Mon, Jan 30, 2006 at 05:02:39AM +0100, Jean-Yves Lefort wrote:
> > On Sun, 29 Jan 2006 22:17:19 -0500
> > Kris Kennaway <kris at obsecurity.org> wrote:
> > 
> > > On Mon, Jan 30, 2006 at 04:08:47AM +0100, Jean-Yves Lefort wrote:
> > > > On Sun, 29 Jan 2006 22:10:19 +0100
> > > > Alexander Leidinger <Alexander at Leidinger.net> wrote:
> > > > 
> > > > > On Sun, 29 Jan 2006 20:52:40 +0200
> > > > > Ruslan Ermilov <ru at freebsd.org> wrote:
> > > > > 
> > > > > > I hit this problem attempting to install print/acroread7 on amd64.
> > > > > > It depends on emulators/linux_base-8, which rewrites ${ARCH} from
> > > > > > "amd64" to "i386".  Unfortunately, when linux_base-8 is processed
> > > > > > in a submake, e.g., when I run "make fetch-recursive" in
> > > > > > print/acroread7, no rewrite of ${ARCH} actually happens because
> > > > > > bsd.port.mk mistakenly thinks that ${ARCH} can never change, so
> > > > > > it's getting passed ARCH already set to "amd64", and as a highest
> > > > > > priority command-line type make(1) variable.  This results in
> > > > > > ${MD5_FILE} improperly set to distinfo.amd64 which doesn't exist.
> > > > > > Here's a fix:
> > > > > > 
> > > > > > %%%
> > > > > > Index: bsd.port.mk
> > > > > 
> > > > > For this particular problem: acroread7 should set ARCH like every other
> > > > > linux port does (better: every other tested linux port should do) to
> > > > > i386. But there are more flaws in Trevor's ports and I decided to let
> > > > > other people "handle" it (e.g. mezz has some patches for acroread7
> > > > > which would let the port behave more to the rules of the porters
> > > > > handbook).
> > > > 
> > > > Any reason to not consider (cluster test) Ruslan's solution?
> > > 
> > > Before I put it on the cluster I'd want reasonable evidence that the
> > > patch isn't going to break more ports than it fixes (which seems
> > > likely to me).
> > 
> > # Get the architecture
> > .if !defined(ARCH)
> > ARCH!=  ${UNAME} -p
> > .endif
> 
> I don't see your point.  The line Ruslan is removing clearly must do
> something, otherwise it can't "fix" the affected ports.  If it does
> something, it needs to be shown that it doesn't do something bad.

The line Ruslan is removing is a performance improvement; its purpose
is to remove the need to execute uname -p in submakes. But since it
passes ARCH as a make argument, it breaks things such as:

.if (${ARCH} == "amd64")
ARCH=           i386
RPMFLAGS+=      --ignorearch
.endif

because the ARCH=i386 assignment is overriden by the ARCH passed on
the submake command line. Removing ARCH from .MAKEFLAGS should fix the
issue without breaking ports.

-- 
Jean-Yves Lefort

jylefort at FreeBSD.org
http://lefort.be.eu.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20060130/0fcf0dfb/attachment.bin