Arch Linux

I am not currently using Haskell, but is in my TODO step list. This will be really _great_.

I thought the Arch Haskell guys provided a repo with all their packages, or is it just a collection of PKGBUILDs?

Anyway, what packages would need to be brought into [community]? More importantly, who will maintain them? One of the Arch Haskell leads is a dev so if he wanted to put them in [community] there is nothing stopping him apart from apparently not wanting to.

Currently everything is being done through the AUR, which is fine, except that there are some packages that keep getting upgraded in the repos that aren't in line with the platform. The main point of this request, and I posted a link on the arch-haskell mailing list, is to at least get the discussion going.

Why not make haskell-platform a group instead of a package?

It's not a package. It's the entire platform and all of it's dependencies.

As long as we can do pacman -S haskell-platform and get it, doesn't matter.

If we had an autobuilder bot, then this would be trivial.

It should be noted that putting Haskell Platform (HP) into community requires a bit of care, especially it's likely to cause problems for users if the PKGBUILD in AUR is used as is together with the current GHC package. GHC 6.10 ships with a basic set of libraries, this set is a subset of the libraries in HP. There are also some libraries that are in both sets, but with different versions, e.g. haskell-time=1.1.2.4 is required by HP while GHC comes with time=1.1.4. The situation for network is similar. Having multiple versions of the same library installed at the same time is fraught with peril, and it's likely that encouraging newcomers to Haskell to use HP will only scare them off.

I see two solutions for this:

1. Make major changes to the GHC 6.10 package and to HP to make sure the situation above is avoided.

2. Wait until HP requires GHC 6.12; this version of GHC doesn't ship with the base set of libraries. (I'm all in favour of early packaging of the next version of HP, as soon as there is a preliminary list of what it contains.)

Without a doubt solution #2 seems like the most sane option. With GHC 6.12.1 in RC status, it seems feasible that early packaging can come soon enough.

On this request: My concern was that the idea may get reject on the basis that the platform doesn't roll incrementally like everything else in Arch. In this case it doesn't seem important to me. When xmonad-light (or whatever it's going to be called) hits the repos, I think that we'll see a giant drop off in GHC downloads; Nearly everyone else left will be coder of some sort. From there every state-of-the-art package will most likely be interesting to those that are deep enough into Haskell to get something out of them.

@Skottish, Yes, #2 would be my preference as well.

On the topic of rolling release: I personally see no difficulty in satisfying both camps, HP has strict depencencies on specific versions of packages, there is of course nothing that prevents those packages to also be avilable in newer versions on AUR (albeit they have to have different names, similar to how some bleeding edge packages are available as X-git or X-svn, maybe we should have haskell-X-hackage).

Also, the HP release schedule calls for a new version every few months, so it's unlikely to lag VERY far behind the bleeding edge of individual packages (except in cases where it makes sense, like parsec2 vs parsec3).

So who do I assign this too? There is no dev/TU in charge of this given the packages do not exist yet in Arch, which would also imply this is not a bug...

The best way to get this done is to convince a dev/TU to bring the packages in. I guess Vegai would be the one to ask. Otherwise, apply to be a TU and do it yourself.

Closing. Not a bug.

Reopened and assigned to me.

And yes, I'm aiming for #2.

One problem is that arch users are eager to report newer versions of libraries, and arch devs/tus are often eager to build+upload those newer versions. And since we don't keep older versions, this will break things like HP easily.

I see three possible scenarios:

1) Leave things the way that they are and keep the regular rolling release model.

2) Push the platform into community and allow anyone that needs alternate versions of libraries to use cabal (multiple or cutting edge versions) or pacman (cutting edge versions) to manage their own repos.

3) Add functionality to pacman to allow for the installation and management of development libraries allowing for users of any language that supports multiple versions to use it to manage their development libraries.

The latter would be ideal and if I had the skills I would submit a patch for review. The middle is certainly acceptable and probably a very good solution seeing that the majority of Haskell downloads in Arch is surrounding xmonad. The former is working at the moment and is certainly the easiest from a distro-package management point of view.

How does haskell handle multiple copies of the same library? Alternative directories or different naming schemes or something else? I'm sure carefully contsructed PKGBUILDs would achieve #3 without any need for patching.

It stores them in a top-down tree structure. For instance using the default cabal setup:

.cabal/
|-- config
`-- packages
`-- hackage.haskell.org
|-- 00-index.tar
|-- 00-index.tar.gz
`-- X11-xft
|-- 0.2
| `-- X11-xft-0.2.tar.gz
`-- 0.3
`-- X11-xft-0.3.tar.gz

Flyspray butchered the formatting, but you get the point.

I think that can be handled by pacman easily without any changes needed.
e.g. have "haskell-platform" provide "x11-xft=0.2" and then provide a x11-xft-0.3 package for those that want something up-to-date.

Or something like that... much like perl does with the system-perl/vendor-perl stuff.

I have a feature request within this feature request: Please leave the HTML documentation in the packages. The docs are very useful and take up little space.

Allan: HP is a metapackage and doesn't actually contain those packages. Although, well... I guess our HP could. However, I asked opinions about this in -dev a couple of weeks back, and the sentiment was against doing that.

Wait, wait wait... disregard that. HP is not just a metapackage, of course. So I concur with Allan's suggestion.

status?

looks like only 'haskell-glut=2.1.2.1' 'haskell-opengl=2.2.3.0' 'haskell-fgl=5.4.2.3' 'haddock=2.7.2' 'haskell-ghc-paths' are missing from community/extra to make full HP2010.2.0.0, right? I wonder - are they not included because there was talk on HP trac if OpenGL/Glut should be removed from HP 2011 or not?

Should this be reassigned to Remy?

No need to afaik.

haskell-platform now in extra

Implemented so that extra has all the packages that make up the platform, and haskell-platform itself is an empty package that depends on those specific versions.