On 2010-10-08 23:49 +0100 (40:5) Magnus Therning wrote:
On 08/10/10 23:04, Peter Simons wrote: [...]
Do we give up on having all of Hackage in AUR and instead rely on tools like bauerbill?
This is interesting idea...
Bauerbill's Hackage support works great. However, in my understanding Bauerbill will generally install the latest version of every package. This is a problem for us, because sometimes we need to withhold updates for a while until all users of the package have updated their packages to cope with the latest version. This is easy to do on AUR, where we can choose which packages to update in which order, but I don't see how that could be accomplished with Bauerbill, unless Xyne is willing to add some major features to the program.
Yes, that is a major drawback indeed.
I could try to add support for version specification when using Hackage. I'm relatively short on time right now though so I don't know how long it would take to implement. It may be unnecessary though. See my comments below concerning the creation of repos. I could also add support for rebuild-chains, e.g. upgrading a particular package would trigger a rebuild of all packages that depend on it,directly and indirectly.
Do we try to do something like what Xyne suggested--set up a Haskell ABS and publish pre-compiled packages in [arch-haskell]?
...however, in the spirit of Arch (in comparison with the Gentoo which I left 3yrs ago), I consider that having kind of 'Haskell overlay' with binary packages would be very nice...
Yes, I agree that this is probably the best solution. Arch was designed to work that way. How difficult is it to set up a repository? Does anyone know how to do that?
I think there are a few Arch devs reading this list, at least a TU or two, hopefully they can offer some more information.
AFAIU it's not much to it really. An ABS-like tree (perhaps kept in a Darcs repo for extra points :-) and a place to upload binary packages and the repo DB to.
A repo is actually quite simple. All it is is a web-accessible directory with the binary packages and the database archive, which can be created automatically with the "repo-add" tool. It is independent of the ABS tree. Each official repo currently includes its own ABS archive. ABS is a bit of a misnomer though, as it's separate from the "abs" package. It's just an archive of directories containing the PKGBUILDs and local source files for each package in the repo. The repo on my site includes such and archive and this is what bauerbill uses to build from source. If the number of internally consistent subsets of haskell packages is fairly limited, e.g. one repo for each version of the Haskell Platform, then my previous idea of supporting multiple repos could be implemented. Bauerbill would not need to support specifying Hackage package versions either as a separate tool would be able to enable the Hackage repo of choice, thereby selecting the correct versions of each package to use. The ABS archive of that repo would enable Bauerbill to build the necessary packages when a rebuild is necessary. As a TU and someone who maintains an online repo, I should be able to help maintain Haskell repos, but as I am still new to Haskell I would clearly need help determining what should be in each repo, at least at first. Regards, Xyne