[arch-haskell] What to do now?

Xyne xyne at archlinux.ca
Sat Oct 9 16:31:27 EDT 2010


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


More information about the arch-haskell mailing list