On 20/06/18 05:54, Eli Schwartz wrote:
> On 06/19/2018 08:28 AM, Allan McRae wrote:
>> On 09/06/18 05:33, Eli Schwartz wrote:
>>> On 06/08/2018 02:18 PM, morganamilo wrote:
>>>> We already ensure arch is an array but if arch is never defined
>>>> this error never triggers. Add an explicit check for a missing arch.
>>>
>>> Good catch! We'd usually abort with
>>> ==> ERROR: foo is not available for the 'x86_64' architecture.
>>>
>>> but not if we're doing some IGNOREARCH operation that doesn't check
>>> this, e.g. --source or --printsrcinfo or --packagelist
>>>
>>> Or, makepkg --ignorearch.
>>>
>>
>> Hrm...  I just saw this after replying the patch was OK.
>>
>> With this patch:
>>
>> $ /home/allan/arch/code/pacman/scripts/makepkg --ignorearch
>> ==> ERROR: arch is not allowed to be empty.
>>
>>
>> I think our current check is OK here and this additional check is too
>> stringent.
>>
>> Allan
> 
> I'll agree with morganamilo here, if someone uses arch=(x86_64) and I
> --ignorearch it to use it on armv7h, that's one thing, but if they don't
> define it at all then --printsrcinfo succeeds but makepkg on its own fails.
> 
> IMHO that makes the patch worthwhile for linting --printsrcinfo, and in
> the process if it results in --ignorearch failing for the same issue,
> then I think it's a good thing on the grounds of technical correctness.
> 
> The PKGBUILD is fundamentally wrong to be missing required variables, it
> shouldn't be "okay as long as you call makepkg with certain switches to
> infer the arch", it doesn't work in the common case. Therefore it should
> be fixed, and we should ensure that --printsrcinfo fails early.
> 
> Yes, anyone who tries to build the package will notice the issue. But
> unfortunately many people who try writing PKGBUILDs will only ever run
> --printsrcinfo and not try building it -- this patch prevents that from
> occurring.
> 

man makepkg:

-A, --ignorearch
Ignore a missing or incomplete arch field in the build script.

The documentation defines the behaviour of --ignorearch as currently
specified.

Allan

Reply via email to