[arch-haskell] Arch Haskell Policy Proposal

[Xyne]

> > Considering the complexity of this issue, perhaps it would be a good
> > idea to create independent haskell repos to host compatible binary
> > packages and/or an official AUR-clone for all of the current haskell
> > packages in the AUR. You could then support the latest stable versions
> > in the offical repos and maintain compatible packages for them in the
> > AUR, and let users who require the latest versions use the official
> > haskell repository and AUR-clone (or just cabal2arch) to acquire the
> > very latest versions.
> 
> This is an interesting idea, especially if we get some tool support
> for that.  AFAIK all "AUR builders" (yaourt, paktahn, etc) only know
> about AUR, so they need to be made a bit more configurable.

The official repos along with some others, such as my own, include a
tarball named $repo.abs.tar.gz. This tarball contains all of the
PKGBUILDs and local source files required to build the packages in the
given repo from source. If someone were able to provide the
aforementioned Haskell repos with these archives included, Bauerbill
would already be able to build from them as it uses these archives to
build from source (which was a design decision to make it more
versatile than it would have been had it used the official ABS tree).

If such a scheme is not possible, I would still be willing to try to
implement support for an alternative scheme.




> The biggest problem I see is that while GHC supports having multiple
> version of the same module available at the same time, pacman doesn't.
>  That would mean that keeping a binary and an AUR version of the same
> package requires that they have different names.  Not a big problem
> really, but it should be policed a bit.
> 
> The bigger problem that users *will* run into is diamond dependency
> issues (A uses B and C, both B and C use D but different versions).  I
> believe that avoiding that would require a *very* strict policy on
> what goes into both binary repos and AUR.  Too strict to follow the
> "Arch way", I think.

If a reasonable naming scheme is chosen and if different versions of
the same package can install to different locations to avoid file
conflicts, you can use "provides" without "conflicts" to satisfy such
dependencies. As already mentioned, this might expose limitations with
some AUR frontends, but it would be ridiculous to work around such
limitations rather than expect the developers of those applications to
address them. The viability of this probably depends on how many
versions of each package one would have to support. If there would only
be one version per ghc version, then maybe this could be included in
the name, or if they are targeted at different releases of the Haskell
platform then use that version in the name.

It should also be possible to create a tool to manage Haskell packages
(installation of specified versions, dependency resolution, etc) that
could then update Pacman's local database to enable global removal of
such packages with Pacman while leaving the complexities of finer
management to a dedicated tool. This would necessarily add some
complexity but it might lead to less complexity overall by eliminating
the need to manage multiple versions of packages across the repos and
the AUR. It should also provide finer control to users who need it.
This way you would only need to manage the latest stable releases in
the repos and the AUR and users who need something else could handle
that themselves with this tool.