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

[Alexander Leidinger]

Kris Kennaway <kris at obsecurity.org> wrote:

>> But since it
>> passes ARCH as a make argument, it breaks things such as:
>>
>> .if (${ARCH} == "amd64")
>> ARCH=           i386
>> RPMFLAGS+=      --ignorearch
>> .endif
>
> How many ports do that?

Nearly every linux port which is known to work on amd64 does something like
this.

>> 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.
>
> Perhaps you can just do the same thing, and pass in the new ARCH to
> the port build as a make argument.

I want to highlight the fact, that the current way of doing it highlighted
the "bug" that acroread7 isn't "certified" for the use on amd64. Someone has
to handle the ARCH part in the acroread port as other linux-XXX ports on
amd64 handle this. If it works on amd64, a committer who isn't bored to
interact with Trevor should then commit this "certification" (it's just
setting ARCH to i386 in the amd64 case).

Are there other ports which are affected by this? If yes, how many of them
are not linux ports?

I only expect linux ports to be affected by the current way of handling ARCH
in bsd.port.mk. And they are affected by this, because nobody cared to test
them in the appropriate way on amd64 and commit/submit the "blessing" for
amd64.

Bye,
Alexander.

-- 
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID = 72077137
You will receive a legacy which will place you above want.