Change Details

= Haskell stack update = The whole Haskell stack has not been upgraded for almost 4 years now: | Package | Currently in repo | Latest available | | --- | --- | --- | | `ghc` | 8.6.5 | 9.6.1 | | `haskell-cabal-install` | 2.4.0.0 | 3.10.1.0 | | `haskell-stack` | 2.1.3.1 | 2.9.3 | | `pandoc` | 2.5 | 3.1.2 | | ... | | | == Problems == There are several factors that make upgrading difficult (which is why it has not been done for so long). Early on it was decided to provide only dynamically linked binaries for Haskell applications. This is the way other distros (like [[ https://wiki.archlinux.org/title/haskell#Configuration | Arch ]]) package Haskell apps, so it seemed reasonable at the time. In theory it allows reuse of common library dependencies between applications and result in a smaller footprint of binary artifacts. However, the reality is that specifically in Haskell stack there are much more intermediate dependency libraries than actual applications that depend on them. There are about 300 packages in the stack (reverse dependencies of `ghc`) and maybe a dozen actual applications. For example `pandoc` has almost 100 dependencies by itself. Moreover different packages may have conflicting dependencies, requiring either ~~hacking~~ patching these packages or forcing upgrade of a lot of dependencies, which might include `ghc` itself. This makes upgrading the whole stack and keeping applications up-to-date incredibly difficult and time-consuming. == Solution == Together with the Core Team we have decided to go away with dynamic linking approach and rebuild the whole Haskell stack statically. This means that the actual package resolution will be delegated to either `cabal` or `stack` freeing us from Haskell dependency hell, which we found ourselves in. It should greatly reduce the number of maintained packages, eliminate dependency conflicts and enable more frequent application updates. However, it will also increase binary footprint of each application. Although with the number of applications compared to dependencies it is not obvious how cumulative footprint changes if we include all library dependencies. == Plan == [ ] Outline the whole Haskell stack graph (with help of tools like [[ https://github.com/biqqles/eon | eon ]]) [ ] Switch current versions of applications to static linking (might require temporary downgrade) [ ] `haskell-cabal-install` [ ] `haskell-stack` [ ] `pandoc` [ ] `pandoc-crossref` [ ] `pandoc-citeproc` [ ] `pandoc-include-code` [ ] `shellcheck` - D14091 [ ] `xmonad` [ ] `xmonad-contrib` [ ] `vgrep` - D14096 [ ] `bustle` - D14119 [ ] `cpphs` - D14118 [ ] Deprecate no longer used packages [ ] Upgrade `ghc` to 9.6.1 (might require multiple bootstrapping steps) [ ] Upgrade remaining applications [ ] `haskell-cabal-install` [ ] `haskell-stack` [ ] `pandoc` [ ] `pandoc-crossref` [ ] `pandoc-citeproc` [ ] `pandoc-include-code` [ ] `shellcheck` [ ] `xmonad` [ ] `xmonad-contrib` [ ] `vgrep` [ ] `bustle` [ ] `cpphs`

= Haskell stack update = The whole Haskell stack has not been upgraded for almost 4 years now: | Package | Currently in repo | Latest available | | --- | --- | --- | | `ghc` | 8.6.5 | 9.6.1 | | `haskell-cabal-install` | 2.4.0.0 | 3.10.1.0 | | `haskell-stack` | 2.1.3.1 | 2.9.3 | | `pandoc` | 2.5 | 3.1.2 | | ... | | | == Problems == There are several factors that make upgrading difficult (which is why it has not been done for so long). Early on it was decided to provide only dynamically linked binaries for Haskell applications. This is the way other distros (like [[ https://wiki.archlinux.org/title/haskell#Configuration | Arch ]]) package Haskell apps, so it seemed reasonable at the time. In theory, it allows the reuse of common library dependencies between applications and results in a smaller footprint of binary artifacts. However, the reality is that specifically in the Haskell stack there are many more intermediate dependency libraries than actual applications that depend on them. There are about 300 packages in the stack (reverse dependencies of `ghc`) and maybe a dozen actual applications. For example `pandoc` has almost 100 dependencies by itself. Moreover, different packages may have conflicting dependencies, requiring either ~~hacking~~ patching these packages, or forcing the upgrade of a lot of dependencies, which might include `ghc` itself. This makes upgrading the whole stack and keeping applications up-to-date incredibly difficult and time-consuming. == Solution == Together with the Core Team, we have decided to go away with the dynamic linking approach and rebuild the whole Haskell stack statically. This means the actual package resolution will be delegated to either `cabal` or `stack` freeing us from Haskell dependency hell, which we found ourselves in. It should greatly reduce the number of maintained packages, eliminate dependency conflicts and enable more frequent application updates. WIP: the repo will follow the version on Stackage. However, it will also increase the binary footprint of each application. Although with the number of applications compared to dependencies it is not apparent how cumulative footprint changes if we include all library dependencies. The only two exceptions to this rule are `haskell-cabal-install` and `xmonad`. The former is because Cabal is required to bootstrap the entire stack; the latter is because `xmonad` changes config by recompiling, so its full dependencies must be available. Consequently, all of the two package dependencies need to be dynamically linked. Fortunately, this list is much smaller, with less than 30 packages needed. For users who still need to develop Haskell, we will provide `ghcup`, the official Haskell tool to install GHC, Cabal, Stack, and Haskell Language Server. The `ghc`, `haskell-cabal-install` packages in the Solus repo should be used solely for packaging purposes only, not for user use. == Plan == WIP: update the list of packages we need to keep & dynamically link. [ ] Deprecate no longer used packages [ ] Upgrade `ghc` from current (9.6.5) to 8.10.7 [ ] Upgrade `ghc` from 8.10.7 to 9.2.8 [ ] Upgrade remaining applications [ ] `haskell-cabal-install` [ ] `haskell-stack` [ ] `pandoc` [ ] `pandoc-crossref` [ ] `pandoc-citeproc` [ ] `pandoc-include-code` [ ] `shellcheck` [ ] `xmonad` [ ] `xmonad-contrib` [ ] `vgrep` [ ] `bustle` [ ] `cpphs`

= Haskell stack update = The whole Haskell stack has not been upgraded for almost 4 years now: | Package | Currently in repo | Latest available | | --- | --- | --- | | `ghc` | 8.6.5 | 9.6.1 | | `haskell-cabal-install` | 2.4.0.0 | 3.10.1.0 | | `haskell-stack` | 2.1.3.1 | 2.9.3 | | `pandoc` | 2.5 | 3.1.2 | | ... | | | == Problems == There are several factors that make upgrading difficult (which is why it has not been done for so long). Early on it was decided to provide only dynamically linked binaries for Haskell applications. This is the way other distros (like [[ https://wiki.archlinux.org/title/haskell#Configuration | Arch ]]) package Haskell apps, so it seemed reasonable at the time. In theory, it allows the reuse of common library dependencies between applications and results in a smaller footprint of binary artifacts. However, the reality is that specifically in the Haskell stack there are muchmany more intermediate dependency libraries than actual applications that depend on them. There are about 300 packages in the stack (reverse dependencies of `ghc`) and maybe a dozen actual applications. For example `pandoc` has almost 100 dependencies by itself. Moreover, different packages may have conflicting dependencies, requiring either ~~hacking~~ patching these packages, requiring either ~~hacking~~ patchor forcing these packages or forcinge upgrade of a lot of dependencies, which might include `ghc` itself. This makes upgrading the whole stack and keeping applications up-to-date incredibly difficult and time-consuming. == Solution == Together with the Core Team, we have decided to go away with the dynamic linking approach and rebuild the whole Haskell stack statically. This means that the actual package resolution will be delegated to either `cabal` or `stack` freeing us from Haskell dependency hell, which we found ourselves in. It should greatly reduce the number of maintained packages, eliminate dependency conflicts and enable more frequent application updates. WIP: the repo will follow the version on Stackage. However, it will also increase the binary footprint of each application. Although with the number of applications compared to dependencies it is not apparent how cumulative footprint changes if we include all library dependencies. The only two exceptions to this rule are `haskell-cabal-install` and `xmonad`. The former is because Cabal is required to bootstrap the entire stack; the latter is because `xmonad` changes config by recompiling, so its full dependencies must be available. Consequently, all of the two package dependencies need to be dynamically linked. Fortunately, this list is much smaller, with less than 30 packages needed. For users who still need to develop Haskell, we will provide `ghcup`, the official Haskell tool to install GHC, Cabal, Stack, and Haskell Language Server. The `ghc`, it will also increase binary footprint of each application.`haskell-cabal-install` packages in the Solus repo should be used solely for packaging purposes only, Although with the number of applications compared to dependencies it is not obvious how cumulative footprint changes if we include all library dependenciesnot for user use. == Plan == [ ] Outline the whole Haskell stack graph (with help of tools like [[ https://github.com/biqqles/eon | eon ]]) [ ] Switch current versions of applications to static linking (might require temporary downgrade) [ ] `haskell-cabal-install` [ ] `haskell-stack` [ ] `pandoc` [ ] `pandoc-crossref` [ ] `pandoc-citeproc` [ ] `pandoc-include-code` [ ] `shellcheck` - D14091 [ ] `xmonad` [ ] `xmonad-contrib` [ ] `vgrep` - D14096 [ ] `bustle` - D14119WIP: update the list of packages we need to keep & dynamically link. [ ] `cpphs` - D14118 [ ] Deprecate no longer used packages [ ] Upgrade `ghc` to 9from current (9.6.1 (might require multiple bootstrapping steps)5) to 8.10.7 [ ] Upgrade `ghc` from 8.10.7 to 9.2.8 [ ] Upgrade remaining applications [ ] `haskell-cabal-install` [ ] `haskell-stack` [ ] `pandoc` [ ] `pandoc-crossref` [ ] `pandoc-citeproc` [ ] `pandoc-include-code` [ ] `shellcheck` [ ] `xmonad` [ ] `xmonad-contrib` [ ] `vgrep` [ ] `bustle` [ ] `cpphs`