On 25 August 2010 15:18, Mathew de Detrich 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.ebui... ) 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@gmail.com IvanMiljenovic.wordpress.com