Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#16816 - Maybe it's time to move the Haskell Platform to Community?

Attached to Project: Community Packages
Opened by Skottish (skottish) - Saturday, 24 October 2009, 02:22 GMT
Last edited by Vesa Kaihlavirta (vegai) - Friday, 11 March 2011, 07:00 GMT
Task Type Feature Request
Category Packages
Status Closed
Assigned To Vesa Kaihlavirta (vegai)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 8
Private No



Arch is becoming one of the premiere Linux platforms for Haskell development thanks to the people working on Arch-Haskell. There's a reoccurring theme on their mailing list about bringing the Haskell Platform to Community, and I feel that it's a great opportunity for Arch. I understand that it doesn't have hundreds of votes, but since there's a group of people who are more than qualified to do it, have a vested interest in Haskell's future, and are currently generating high quality PKGBUILDs and install files, I think that it would be good for Arch and Haskell hackers alike to make this move.

This task depends upon

Closed by  Vesa Kaihlavirta (vegai)
Friday, 11 March 2011, 07:00 GMT
Reason for closing:  Fixed
Additional comments about closing:  haskell-platform-2011.2.0.0
Comment by Gerardo Exequiel Pozzi (djgera) - Saturday, 24 October 2009, 02:36 GMT
I am not currently using Haskell, but is in my TODO step list. This will be really _great_.
Comment by Allan McRae (Allan) - Saturday, 24 October 2009, 02:44 GMT
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.
Comment by Skottish (skottish) - Saturday, 24 October 2009, 03:00 GMT
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.
Comment by Abhishek Dasgupta (abhidg) - Saturday, 24 October 2009, 04:52 GMT
Why not make haskell-platform a group instead of a package?
Comment by Skottish (skottish) - Saturday, 24 October 2009, 05:10 GMT
It's not a package. It's the entire platform and all of it's dependencies.
Comment by Abhishek Dasgupta (abhidg) - Saturday, 24 October 2009, 05:14 GMT
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.
Comment by Magnus Therning (magus) - Saturday, 24 October 2009, 05:24 GMT
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= 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.)
Comment by Skottish (skottish) - Sunday, 25 October 2009, 03:47 GMT
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.
Comment by Magnus Therning (magus) - Sunday, 25 October 2009, 07:47 GMT
@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).
Comment by Allan McRae (Allan) - Sunday, 25 October 2009, 08:28 GMT
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.
Comment by Vesa Kaihlavirta (vegai) - Thursday, 03 December 2009, 09:39 GMT
Reopened and assigned to me.
Comment by Vesa Kaihlavirta (vegai) - Thursday, 03 December 2009, 09:43 GMT
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.
Comment by Skottish (skottish) - Tuesday, 08 December 2009, 02:05 GMT
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.
Comment by Allan McRae (Allan) - Tuesday, 08 December 2009, 02:21 GMT
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.
Comment by Skottish (skottish) - Tuesday, 08 December 2009, 04:50 GMT
It stores them in a top-down tree structure. For instance using the default cabal setup:

|-- config
`-- packages
|-- 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
Comment by Skottish (skottish) - Tuesday, 08 December 2009, 04:51 GMT
Flyspray butchered the formatting, but you get the point.
Comment by Allan McRae (Allan) - Tuesday, 08 December 2009, 05:43 GMT
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.
Comment by Skottish (skottish) - Thursday, 10 December 2009, 05:00 GMT
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.
Comment by Vesa Kaihlavirta (vegai) - Wednesday, 20 January 2010, 12:31 GMT
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.
Comment by Vesa Kaihlavirta (vegai) - Wednesday, 20 January 2010, 13:22 GMT
Wait, wait wait... disregard that. HP is not just a metapackage, of course. So I concur with Allan's suggestion.
Comment by Thomas Dziedzic (tomd123) - Saturday, 03 July 2010, 23:19 GMT
Comment by Andrzej Giniewicz (Giniu) - Thursday, 21 October 2010, 15:26 GMT
looks like only 'haskell-glut=' 'haskell-opengl=' 'haskell-fgl=' '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?
Comment by Kaiting Chen (kaitocracy) - Tuesday, 14 December 2010, 05:12 GMT
Should this be reassigned to Remy?
Comment by Vesa Kaihlavirta (vegai) - Tuesday, 14 December 2010, 17:19 GMT
No need to afaik.
Comment by Vesa Kaihlavirta (vegai) - Friday, 11 March 2011, 07:00 GMT
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.