[arch-haskell] Starting to help
simons at cryp.to
Sun Jun 26 17:39:54 CEST 2011
> 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
> 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
> 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
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:
../../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.
More information about the arch-haskell