[arch-haskell] Starting to help

[Peter Simons]

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