Arch Linux User Repository

I see no problem providing a -bin package for a slotted compiler, and it already exists at https://aur.archlinux.org/packages/ghc8.4-bin/ so you just need to makedepends on it, surely...

Alright, this package now uses ghc8.8 to build: https://aur.archlinux.org/cgit/aur.git/commit/?h=gitit&id=468cb35201aaaaabc3cf1e6ce66cfd54a42ed113

I see no problem providing a -bin package for a slotted compiler, and it already exists at https://aur.archlinux.org/packages/ghc8.4-bin/ so you just need to makedepends on it, surely...

Wouldn't it make more sense to use the source code of GHC in the sources

It was chosen out of practicality. The upstream already offers GHC binaries so it was more expedient to download the official binary than to try to build from source.

If the mixture of binary and source is a concern, I could, say, refactor the compiler into a separate ghc-X.Y-bin package, but in general I am not certain of the etiquette with regards to littering AUR with multiple versions of the same package.

What do you mean by slotted packages? Are you suggesting populating AUR with version-specific packages like haskell-foolib-0.1.2.3?

I'm not suggesting you do anything. I'm clarifying that you're incorrect to claim it's not "possible" to have version-specific packages like haskell-foolib-0.1.2.3

It was more robust to pin to a specific version of GHC rather than to rely on the latest.

Once again, you could simply makedepends on an AUR package "ghc-8.8.4" and expect people to build this from source as a makedepends.

In this case it's much more eyebrow-raising since when it came to slotted libary packages you decided it wasn't worth it and built 200 of them from source, but when it came to a compiler you decided to use a prebuilt binary. Wouldn't it make more sense to use the source code of GHC in the sources, and build the compiler during build(), then use it to compile gitit? And once you're building the needed compiler from source, doesn't it make sense to have it as a separate package?

You already maintain a ghc-8.6 package, and another user maintains a ghc8.4 package.

you can have slotted packages as a general thing on Arch

What do you mean by slotted packages? Are you suggesting populating AUR with version-specific packages like haskell-foolib-0.1.2.3?

I see no good reason ever to download a binary of the compiler as a source.

Gitit often lags behind in supporting the newer GHC versions. It was more robust to pin to a specific version of GHC rather than to rely on the latest.

It is in principle possible to use the newer ghcup tool to fetch GHC instead of using makepkg, but that is arguably less transparent as the download would still occur but behind the curtains.

The PKGBUILD effectively uses the same strategy that, say, Stack would use to build Haskell code by retrieving a specific version of GHC from upstream. However, Stack doesn't work out of the box for packaging Gitit: https://github.com/jgm/gitit/issues/622#issuecomment-414138353

I do wonder if the code could be patched to play more nicely with Stack. I may be convinced to try that route, but the downside is again the lack of reproducibility and transparency due to the magic that goes on within the Stack build system.

$CARCH cannot be used since it would result in different checksums

Thank you for catching that. The checksum for i686 has been corrected in https://aur.archlinux.org/cgit/aur.git/commit/?h=gitit&id=6338ca11beb23374e668487ece45546261c65e06

Arch only permits a single version to be installed at any time and users would not be happy with having to roll back packages just to please Gitit.

Not really true... you can have slotted packages as a general thing on Arch, which can be installed side-by-side with the newer version (assuming the programming language supports it! C ABI libraries do support it, python import namespaces do not, looking at haskell packages on my system it seems like the only conflicting files would be in /usr/share/haskell/{,un}register/ so maybe this should be fine...)

source=("${source[@]}" "https://downloads.haskell.org/~ghc/8.8.4/ghc-8.8.4-$CARCH-deb9-linux.tar.xz")

This makes me incredibly skeptical though. I see no good reason ever to download a binary of the compiler as a source. Even if you thought it was a good idea, $CARCH cannot be used since it would result in different checksums if people actually used non-x86_64 systems...

Rather than issuing a deletion request, it would be more welcoming to offer a practical alternative to the issues at hand. This package is provided to help mitigate the dependency troubles associated with Gitit, so if there are legitimate alternatives of lower complexity, that would be appreciated.

Ignoring the sheer maintenance burden of introducing numerous packages simply to build Gitit, freezing dependencies is not viable as a long term solution. Arch only permits a single version to be installed at any time and users would not be happy with having to roll back packages just to please Gitit.

The approach taken here is to statically link the libraries that Gitit requires, as is conventional in the ecosystem of Haskell binaries. Arch is unusual in that the official packages are dynamically linked and no static libraries are provided, so it is not even possible to use them to build a static library.

That is not a feasible approach given the number of dependencies.

Rufflewind, PKGBUILDs support versioned dependencies. Dependencies requiring a specific version not available in the Arch repositories should have separate AUR packages created for them and this PKGBUILD should depend on those.

@Repentinus This package has a large number of aging dependencies and runs into version conflicts easily. Freezing dependencies was necessary for getting it to build reproducibly. Stack would have been a good choice but Gitit doesn't play well with that either: https://aur.archlinux.org/cgit/aur.git/commit/?h=gitit&id=c2b9a66c0e6509bb34922c12ffc1d0fd95326b74

Let me know if you have an alternative approach for building Gitit that works reliably.