On 2010/10/15 Magnus Therning
Taking it one step further:
• Replace archhaskell/habs with a single version-controlled file containing tuples of
. • 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.