[arch-haskell] Thoughts on Procedure

[Rémy Oudompheng]

On 2010/10/15 Magnus Therning <magnus at therning.org> wrote:
> Taking it one step further:
>
> • Replace archhaskell/habs with a single version-controlled file
> containing tuples of <package name, package version>.
> • Make use of bauerbill's already existing support for hackage.  (I
> don't know anything about the internals of bauerbill, but it might
> need some extending to closer match what cabal2arch does.)
>
> Then the process would be:
>
> 1. Monitor the RSS feed from hackage.
> 2. Modify the relevant tuples in the file.
> 3. Based on 'git diff' run bauerbill on the updated packages.
> 4. Find the dependants, and re-build them.
> 5. If all is well upload to AUR or the binary repo.
> 6. Rinse and repeat.
>
> All steps could then be wrapped up in a makefile.  Furthermore,
> bauerbill could just have knowledge of the control file we maintain,
> and then step 5 can be skipped.
>
> In any case, I feel that the discussion of what to store in our git
> repo, whether it's Arch source packages or cabal files or tuples,
> isn't that important at this point, i.e. your steps 2-5 are the steps
> to concentrate on.  If we are going to attempt maintaining more than a
> handful binary packages then we'll get most value out of automating
> the time consuming bits of that.  Remy is hard at work on pieces of
> that, but there's more to be worked out.

Xyne may confirm that, but bauerbill is merely a wrapper around
cabal2arch and pacman, which probably resolves dependencies in the
ArchLinux way and not in the Cabal way. I would dream of Cabal 2 [#]
to do things in the most (in my opinion) satisfactory way.

If we do not have an option to install cabal-install as a library, I
don't think this is indeed necessary. The 'cabal-query' library gives
a very nice example of how we could manage a habs tree purely in
memory.

1. I support version-controlling a single package list file. It would
be a good idea to get rid of package lists stored in archlinux-web
2. I suggest to add a small Distribution.Archlinux.ArchPackage module:
which would manage a data structure like this:
    { pkg :: PkgBuild, installscript :: String, otherfiles :: [String] }
   It would give a complete internal representation of a Archlinux
package and would provide interested developers a Haskell way of
managing generic packages (i.e. not necessarily Haskell packages)
2. I would like to move Cabak2Pkgbuild translation to a
Distribution.Archlinux.CabalTranslation module, for example.
cabal2arch would keep the command line interface with its options, and
additional scripts for the steps you mention.
3. I would like to add a Distribution.Archlinux.HackageTranslation
module, that would be able to process a tarball downloaded from
Hackage and output a SrcRepo structure for example.

I think CabalTranslation of exposing a function

packageFromCabal :: PackageDescription -> Maybe a -> Maybe b -> ArchPackage
- taking as arguments a Cabal package,
optionally a list of dependencies to clear out,
optionally a translation table
- putting out a ArchPackage structure.

It would give the following modules:

generic package generation and handling :
  Distribution.Archlinux.PkgBuild
  Distribution.Archlinux.ArchPackage
  Distribution.Archlinux.SrcRepo
interaction with Cabal and Hackage (no IO) :
  Distribution.Archlinux.CabalTranslation
  Distribution.Archlinux.HackageTranslation

-- 
Rémy.