Add support for 64-bit SPARC as a separate architecture

[glaubitz]

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
• The documentation has been updated, if necessary.
• Manual QA notes have been included.

Previously, sparc64 was defined as an alias for the 32-bit SPARC architecture which was true while SPARC mainland was mostly 32 bits. More recently, 64-bit SPARC has become a port of its own, so it needs to be treated as a separate architecture.

[Mikolaj]

@glaubitz: thank you for the PR. CI indicates package hashes change and I suspect that also implies that this change should be guarded behind cabal-version 3.12. @phadej: am I right? BTW, is there any ready resource for developers explaining how to guard behind a cabal version or even when exactly this is necessary (just when inducing any PvP change in Cabal-syntax?)?

[glaubitz]

@glaubitz: thank you for the PR. CI indicates package hashes change and I suspect that also implies that this change should be guarded behind cabal-version 3.12. @phadej: am I right? BTW, is there any ready resource for developers explaining how to guard behind a cabal version or even when exactly this is necessary (just when inducing any PvP change in Cabal-syntax?)?

Is there a manual which explains how to update the hashes?

[ffaf1]

Just do it manually, @glaubitz. Check what CI expected, slap it in, commit.

[glaubitz]

Just do it manually, @glaubitz. Check what CI expected, slap it in, commit.

Should be done now and hopefully good for merging. ;)

[ffaf1]

Good AFAICS

[geekosaur]

Otherwise looks okay to me.

[geekosaur]

Is the "sun4" alias here still needed for the 32-bit arch?

[glaubitz]

I have not seen it being used anywhere. And even Solaris is defaulting to a 64-bit userland these days.

[andreabedini]

@Mikolaj @ffaf1 @geekosaur I had a look and I am tempted to say that this does not require a bump in cabal-version.

The role of cabal-version is to help with forward compatibility (see #4899), i.e. let old cabal versions distinguish between something wrong and something from a future they can't understand.

Now, w.r.t to this change there are two factors:

1. As far as I can tell, this change maps "sparc64" to a separate architecture rather than being an alias for "sparc". This alone does not change the allowed input syntax and both old and new versions of Cabal will still be able to parse the same file.
2. The PR also removes the alias "sun4" and this could be a problem. But it is not, because Cabal is perfectly fine with architectures it does not know:

ghci> simpleParsec "x86_64" :: Maybe Arch
Just X86_64
ghci> simpleParsec "my-coffe-machine" :: Maybe Arch
Just (OtherArch "my-coffe-machine")

so also in this case the accepted syntax is not changed.

So 👍 from me.

Note: The hash changes because the data type has changed, but the API is not the same thing has the accepted syntax.

Note: Adding a constructor to an exported data type is a major version change.

[Mikolaj]

That's a relief. @glaubitz, feel free to set a merge label, as described in CONTRIBUTING. We'd still have 2 days for someone to correct us. Thank you, everybody!

[glaubitz]

It says that there 3 checks that are failing and that seems to block the auto-merge.

Anyone can point me to what's failing?

[ffaf1]

@mergify rebase

[mergify]

rebase

✅ Nothing to do for rebase action

[ulysses4ever]

@glaubitz thanks for the ping! The macos failure is transient and requires restarting, which I did. The rest is related to the merge bot Mergify and will have to be dealt with once the macos job succeeds.

[ulysses4ever]

Hooray! 🎉🎉🎉