Hello, I am not experienced in haskell but I wanted to point out the argument with storage is not as simple as it seems. Storage matters still in 2024, if you run an environment where you have a lot of software using the same libraries, you do not want it duplicated over and over again. But its also bandwidth, that is not cheap and it costs a lot of money for the mirrors to provide fast links for users to download binaries. I can give 3 examples of programming languages which bundle or static link: - Go, Go binaries tend to be relatively large after all the dependencies are compiled in. - Rust, I wonder how many times Rustls or tokio is duplicated on a system with high numbers of rust software. Yes I am aware rust binaries are stripped down, but they do tend to produce large bundles. - Java, two words, "Uber Jar". Now I believe this comes down to pragmatism, and you could argue that its more pragmatic to just static link everything. But if package maintainer(s) are willing to maintain haskell libraries, surely it will be less pragmatic to then go back on that and rewrite all the packages to be statically compiled. Also another thing which is a concern for Java, and probably rust and go, but has no "good" solution. All these libraries have their own licenses, some of them are MIT which has a copyright field which should be credited. If each haskell dependency is packaged independently, its license is clearly listed and installed, but in a static linked package surely you would need to go through each dependency, check its license, and then add it to the license array. I discussed this with Artafinde in the past with Java Uber Jars after a developer brought up the question that one of their software which was packaged in Arch Linux only listed their license, and not the licenses on the libraries used. But Artafinde made it clear its upstreams responsibility to provide a file with the dependency licenses. I am aware Java are JIT compiled and thus irrelevant to linking, but they have the same issues as static linking as it comes under the umbrella of "dependency bundling". Also heres a big one, with dynamic linking if the ABI remains the same you don't need to rebuild, if you static link you MUST rebuild each version when a dependency is bumped. Also another thing, Arch Linux is rolling release, one issue I saw when I briefly packaged rust code is that some devs never bump the dependency versions, you could have vulnerable versions of rustls for example which is never bumped, which then needs patching. Wouldn't haskell have a similar issue? If upstream doesn't keep their dependencies up to date, arch team would then need a patchset to keep the dependencies up to date? And then rebuild the software each time there is a issue with a dependency? Then technically they are tracking the dependencies anyways and therefore why not just package them separately? So is it truly more pragmatic or faster? Not a staff member, just found this thread interesting. Sorry if I derailed the original purpose with my own curiosity :) Take care, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@icebound.dev

It's probably not important for this specific case, but just to be clear:

The only benefit is to reduce storage consumption.

That's not entirely true. Depending on how the linker works internally, it can also reduce RAM usage because multiple programs can be mapped to the same code/data in RAM(possibly with a copy-on-write mapping). On Tue, Feb 13, 2024 at 12:43 AM Evan Greenup <evan_greenup@protonmail.com> wrote:

Suggestion

Build executable program written in Haskell statically. (For the convenient of package maintainer, remove Haskell library packages).

Reason

The advantage of dynamic linking is letting multiple executable sharing same part of code. The only benefit is to reduce storage consumption. But in nowadays, storage is getting cheaper and cheaper. It is no longer be a issue now. And Haskell packages are all relatively small.

However, here are a lot of drawbacks for dynamic linking of Haskell ecosystem.

Firstly is dependency version conflict. If two package depend on a same package with exclusive permitted version range, it will be a big trouble. One dependency version update requires Arch Linux package maintainer update a series of packages which depend on this package. (Unlike Python, Haskell is compiled language with low ABI compatibility across different version). lack of link time optimization. Long time of upgrading via pacman. Updating many small package is really much slower than updating one big package. And registering Haskell module take a long time.

Why program written in C/C++ can be distributed in dynamical linking form?

C/C++ has very poor dependency resolver and package manager. C/C++ project need developer take care of dependency manually. And C/C++ compiler provide relatively stable ABI. None of those condition applies to Haskell.

Details of Action

Only providing:

ghc exclusive to ghcup ghcup provide ghc, stack, cabal-install. This is similar to rustup package. haskell-language-server like other Haskell executables, statically linked.

When user install ghcup via pacman , the need to manually set default toolchain to install ghc and other tools.

All non-executable Haskell library become unnecessary. Since no Haskell developer will use haskell package provided by the Linux distro.

Expected Benefit

package maintainer will save a lot of time on maintaining Haskell software. update will be much quicker. All Haskell program packages can easily up-to-date.

I believe the gain of this suggestion is significantly greater than the loss.

Evan