[Haskell-cafe] Hackage on Linux

[Ivan Lazar Miljenovic]

On 25 August 2010 15:18, Mathew de Detrich <deteego at gmail.com> wrote:
> The thing is, libraries at least should be automated. There are just way too
> many packages in Hackage for someone to go through and manually check if
> something goes wrong, and you get the issues described previously in
> conflicts of latest version and outdated versions of libraries installed
> through AUR/cabal (and in my case having to manually go through and use
> cabal2arch to fix things was taking up way too much time). C/C++ libraries
> can be checked by hand because there aren't many of them (as mentioned
> earlier) where as the 'Haskell' way of doing things is using lots of
> smaller modularized libraries.

Well, this is my (unofficial policy) of how to deal with libraries and
packages in the Haskell overlay for Gentoo:

* Unless required by the Haskell Platform, etc. keep at most one major
version of each package (for packages like Parsec, keep one 2.x series
and one 3.y series version)

* Don't keep around useless packages: if I find a package that has had
a newer version on Hackage for 6 months or more, then it's quite
likely that no-one cares about that package.  In that case, if it will
be too difficult to build and test a new version (e.g. something
approaching the complexity of yi's ebuild:
http://code.haskell.org/gentoo/gentoo-haskell/app-editors/yi/yi-0.6.2.4.ebuild
) then get rid of it; if the package has rather simple build
requirements, then consider bumping it on a case-by-case basis.

Note that I keep a rather large selection of Haskell packages
installed so that I can keep an eye on when new versions come out
(using "cabal update && cabal upgrade --dry-run").  For example, I
don't use yi, but I keep it installed solely because of the large
number of dependencies it has.

About 10 months ago, I went on a "spring clean" of the overlay; going
alphabetically I got down to Cabal before I gave up due to the sheer
number of packages that were affected by one of the above two
criteria.  Most of the packages removed due to the second criteria
where those that someone thought "that looks cool, let's make an
ebuild for it" and then it never actually got used.

I add packages typically due to one of two reasons:

* I want that package (or else something I have installed has a new
version that wants that package).

* Someone requests it (preferably via IRC).

Some are still added due to the "cool" factor; typically I try to
restrain myself from doing so unless I'm also going to install it to
keep track of it (e.g. criterion; I haven't seriously used it but I
keep it installed to also ensure that vector{,algorithms}, statistics,
etc. are kept up-to-date; I also keep hmatrix installed despite only
needing it for one semester a few years back for the same reason).
Otherwise, it's just going to grow out of control.

So, in essence I try to ensure that we keep the overlay as a "curated"
version of Hackage (and I typically do more package maintenance in the
overlay than kolmodin or slyfox, who play more with GHC, etc.).  I'm
not saying that my decisions are necessarily correct on whether
something is worth keeping or not, but this way we try to avoid creep
of useless, unmaintained distribution packages.

(If there is a package you want that's not in there, either ping me on
IRC or email me; but there are no guarantees of it being kept
up-to-date with the latest version unless I decide I want to install
it myself as well.).

> If people just wanted an auto udpate version of cabal that works through
> arch's package management, then there should have just been a pacman wrapper
> which when you install/update haskell libraries/packages, it creates a local
> package through cabal2arch instead of using AUR.
> You either have everything properly updated (assuming it doesn't fail
> building for w/e reason) or if you want to 'clone' cabal onto AUR, then only
> do it for the necessary/base/required packages which is easy to keep track
> of

Yeah, I don't like that solution, as I mentioned a few emails back: if
nothing else because of the inability of properly tracking non-Haskell
dependencies properly.

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
IvanMiljenovic.wordpress.com