Change Details

= Haskell stack upgrade = 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 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 if possible [ ] `haskell-cabal-install` [ ] `haskell-stack` [ ] `pandoc` [ ] `pandoc-crossref` [ ] `pandoc-citeproc` [ ] `pandoc-include-code` [ ] `shellcheck` [ ] `xmonad` [ ] `xmonad-contrib` [ ] `vgrep` [ ] `bustle` [ ] `gtk2hs-buildtools` [ ] `cpphs` [ ] Deprecate no longer used packages [ ] Upgrade the whole stack [ ] 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` [ ] `gtk2hs-buildtools` [ ] `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 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 if possible [ ] `haskell-cabal-install` [ ] `haskell-stack` [ ] `pandoc` [ ] `pandoc-crossref` [ ] `pandoc-citeproc` [ ] `pandoc-include-code` [ ] `shellcheck` [ ] `xmonad` [ ] `xmonad-contrib` [ ] `vgrep` [ ] `bustle` [ ] `gtk2hs-buildtools` [ ] `cpphs` [ ] Deprecate no longer used packages [ ] Upgrade the whole stack [ ] 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` [ ] `gtk2hs-buildtools` [ ] `cpphs`

= Haskell stack upgrade =date = 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 if possible [ ] `haskell-cabal-install` [ ] `haskell-stack` [ ] `pandoc` [ ] `pandoc-crossref` [ ] `pandoc-citeproc` [ ] `pandoc-include-code` [ ] `shellcheck` [ ] `xmonad` [ ] `xmonad-contrib` [ ] `vgrep` [ ] `bustle` [ ] `gtk2hs-buildtools` [ ] `cpphs` [ ] Deprecate no longer used packages [ ] Upgrade the whole stack [ ] 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` [ ] `gtk2hs-buildtools` [ ] `cpphs`