Hi Fabio,
yesterday I submitted a patch to HABS repository just because I met some out-of-date packages in AUR. Then I read the "story" of this group in this mailing list and thought that I can give some help. I think I can take responsibility for a bunch of packages and care for updates, but I need some hints.
your pull request has been merged. Thank you very much for the contribution!
1) In order to test for broken packages, do I really need to use the makeworld script? I think it would take too much time!
Unfortunately, distributing Haskell packages is a fairly complicated affair, mostly because these packages interact with each other in complex ways. Some problems can be caught without running a test build, but not all of them. My experience is that running 'makeworld' is the only way to be sure that the repository is in a consistent state. The procedure looks intimidating at first, but it's not that complicated, actually. Initially, the script runs for quite a while, because it needs to set-up the chroot build environment, but once that's been accomplished, builds are fairly quick. Note that the script does not build everything from scratch -- rather, it builds only those packages that need to be re-built. So, if at all possible, I'd encourage you to use 'makeworld'. If you don't want to (or can't, for some reason), then it's fine too, though, because others do run it and will catch problems eventually.
2) Past discussions suggest me that the group is centred on a small number of packages to put in a binary repository. It's wonderful to have this, but it takes a very long time. What do you think if some people concentrate in the simplest and fastest task of preparing PKGBUILDs and put them in a place (i.e. AUR) where the core group decide witch package worth an inclusion in the repo?
It is possible to update packages on AUR without building them first. So, yes, we could split this effort into one that updates AUR and one that maintains the binary repository. Past experience suggests, though, that packages that are being published without being built first tend to be very unreliable. This means that users will run into build problems, and then they'll complain on AUR or on this list -- and rightfully so! Dealing with those issues, however, is a lot of effort. I'm not sure whether publishing untested PKGBUILDs is going to be very helpful for the general user base.
Anyway I'd prefer the mainter to be the group, not a single. That's only my opinion, of course.
Yes, I very much agree. This is a community-driven effort that is intended to allow everyone to contribute and to have an immediate impact on the result.
3) For Peter: could you please give some help information on how to use the scripts in https://github.com/peti/arch-haskell/tree/master/scripts ?
I'll try to describe my work-flow briefly: 1) Clone the 'peti/arch-haskell' repository. 2) Run "git submodules init" to set-up the HABS tree. 3) Run "cabal update" to download the latest database from hackage. 4) Run "make" to re-build all files in HABS based on the configuration that's described in the PKGLIST file. The format of that file is: | haskell-aes AES 0.2.8 1 ^^^^^^^^^^^ ^^^ ^^^^^ ^ $pkgname $_hkgname $pkgver $pkgrel 5) Run "git diff" in the habs/ sub-directory to verify the changes. Then commit those changes in habs/. 6) Run "make world" to build the latest version of the binary repository. 7) If all went well, push the updated version of habs/ to Github. Furthermore, you can run ... * "make updates" to get a list of all updates available on Hackage. Edit PKGLIST to pull in those updates that you want, then run "make all" to verify that all version constraints can be fulfilled. This is usually an iterative process, in which one package after another is updated until all updates that can be performed have been found. * If habs/ has been changed by another committer, you can run "scripts/extract-pkglist habs/habs/* >PKGLIST" to synchronize the PKGLIST file with the current state of the repository. * If you have updated packages "foo" and "bar" in habs, then run: make scripts/reverse-dependencies cd habs/habs ../../scripts/reverse-dependencies . foo bar This will show you the list of packages that need to be re-built after that update. If that looks okay, run ../../scripts/bump $(../../scripts/reverse-dependencies . foo bar) to bump the $pkgrel of all those packages. Commit those changes in habs/. Then run scripts/extract-pkglist habs/habs/* >PKGLIST to synchronize the PKGLIST file, and do the usual "make all && make world" routine to verify that everything is okay before pushing the changes to Github. It's a bit of a mess, but it works okay. :-)
4) Why haskell packages in extra depends on ghc-7.0.3 (still in testing)?
There is an update of GHC available in [testing], and unfortunately some packages have been published that were built with that newer GHC version before GHC itself is available. In short, Haskell support is currently broken in ArchLinux. Unfortunately, these things happen, but it's most probably going to be remedied soon. Take care, Peter