While looking at Haskell binary ports, a couple of approaches seem
1) Embed Haskell libraries into ports, build binaries from them.
2) Build binaries with `cabal new-build`
The status quo is #1. This has a few benefits: it exists, libraries
are reused by multiple ports reducing build costs. There are
drawbacks: the ports tree contains a duplicate (and sometimes
inconsistent) specification of Hackage information. Because of this,
upgrades are a big pain and there's a version of DLL (cabal) hell in
that a single compatible library version needs to be chosen for all
An alternative is #2. Many hs-* library ports could go away by making
each binary port (e.g. darcs, shellcheck) build their own library
dependencies in its sandbox. This will reduce maintenance costs and
avoid any possibility of version conflicts. There are drawbacks: it
doesn't exist, the same library will get built for each binary using
it. We also won't be able to switch to a completely clean #2. Some
ports (e.g. xmonad) use Haskell build as a configuration mechanism. We
still need to provide a subset of ports-embedded libraries in the
style of #1.
If we are to keep doing #1, we should automate maintenance as much as
possible. portgen is an option and so is building a port targeting
version of cabal2bazel (once brought up to date)
If the majority of OpenBSD users only care about using the binaries, I
believe we will serve them better by doing #2 for the binary providing
Some unknowns apply to design #2:
* how well we can specify the Hackage snapshot
* how hermetic we can make it (force tarball fetching to happen
before running `cabal new-build`)
P.S. Ports with Haskell binaries:
% for i in $(</tmp/all-hs ); do grep '^@bin' $i/pkg/PLIST*>/dev/null &&
echo $i; done
All ports (including sub-packages) dependent on ghc:
sqlite> select count(fullpkgpath) from ports where build_depends like
I'm looking for strong negative reactions (if any) to this proposal so I
don't waste any time.
On Sat, Jun 8, 2019 at 9:27 PM Greg Steuck <[hidden email]> wrote:
> While looking at Haskell binary ports, a couple of approaches seem
> 1) Embed Haskell libraries into ports, build binaries from them.
> 2) Build binaries with `cabal new-build`
The main takeaway here is that the approach is workable and we can learn
from their experience.
In particular, custom xmonad configurations require local rebuilding which
isn't hard, but does
mean a beefier machine is needed.