Dear Haskell packagers,
please forward this mail to futher Haskell packagers and put them on CC
At HaL8 Peter (the NixOS Haskell packager) and me talked about our
respective work in packaging Haskell and Peter pointed out that we
duplicate a lot of work, and proposed a closer collaboration. Everyone
of us finds (or creates, using patches) a view on hackage hat is
consistent. The plan is to share this information, which is common
across distributions, so that we can easier benefit from the work of
others. This information consists of
* which packages,
* in what versions,
* with what flags
* and what patches
are packaged.
We would define a format to share this information, and then create
distro-specific and generic tools to work with this data. Such tools
would (possibly)
1. check the cabal constraints for consistency
2. suggest updated
3. build everything in a CI fashion (Peter said he would set a up a
Hydra job for that)
4. create Nix package
5. compare the state with the Debian packaging and list
differences.
We almost have exactly that already at
http://anonscm.debian.org/darcs/pkg-haskell/tools/all-packages/
where packages.txt list packages, versions and flags, and patches/
contains the patches (although only the patches to the .cabal directory,
at this point, I plan to change that.) The test-packages.pl does points
1. and 5. already, so we have something to work with.
The way forward would be to extend this format a bit (but avoiding
overengineering at this point; there will be few tools using this, so
changes to the data layout later will not be bad), creating a repo
somewhere, and then creating the tools. I do not think that we will (or
even should) synchronize our data sets across different repos, but
rather treat them as different branches where we can pull from each
other at need, possibly with a tool that highlights differences.
For the file format, the smallest increment from what we have now would
be to leave packages.txt as simple as it is and change patches to this
format:
.../patches/<pkg>/<version>/<patchname>
and a text file
.../patches/<pkg>/<version>/series
which lists <pathname>’s per line. This has the advantages that if
different distros want a different selection of patches, only the series
file needs to differ. Furthermore this format happens to coincide with
the patch management tool "quilt". The patches may carry meta-data, see
http://dep.debian.net/deps/dep3/ for a useful specification. Especially
the "Forwarded" field will be useful, as we don’t want to bug the author
three times for each bug :-)
Peter said that Darcs as a changes tracker (instead of a state tracker)
might be a good choice for the repository. I’m fine with that (we use
Darcs all over in the Debian Haskell Group), but I would not insist.
There is some overlap with Stackage here, but not completely. It seems
that stackage is more focused on being a QA mechanism for hackage, while
this project would more aim at fixing hackage and bending it into the
shape that we want it to have in the distros.
Greetings,
Joachim
--
Joachim "nomeata" Breitner
Debian Developer
nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata
Attachment:
signature.asc
Description: This is a digitally signed message part