[arch-haskell] Re: [extra] haskell-parallel

[Xyne]

> >>> Hmm, what we would need is so that when haskell-pandoc is being built
> >>> it's
> >>> PKGFILE is updated so that it requires haskell-http 4000.0.9 exactly.
> >>> Then
> >>> an attempt to uninstall haskell-hp-http later would require an
> >>> uninstallation of haskell-pandoc too.
> >>>
> >>> Can pacman be forced to do this? We would need something like a new
> >>> option
> >>> in PKGFILE which would have meaning: "fix versions of dependencies of
> >>> these
> >>> packages exactly to the versions which are currently installed (installed
> >>> during building)."
> >>
> >> Just for reference, this is basically what the Debian policy on
> >> Haskell packages is.
> >>
> > Good policy, if they can have it automated. If pacman (or I should rather
> > say makepkg) has such a option then great. If not we should check whether we
> > can add it there. We want the final exact version for dependency to be fixed
> > during build time. The PKGBUILD files need to contain the version ranges as
> > the cabal files.
> >
> > If we cannot have this late version fix during makepkg then I say just let
> > it be as it is. If a user wants to go into the troubles with the source
> > packages then he/she should be able to take care about knowing and obeying
> > the haskell quirks.
> >
> > Well maybe we could try to provide a small wraper over makepkg (something
> > like haskell-makepkg) which should be used for haskell source packages ...
> > if we cannot get this fixed in the makepkg itself.
> 
> A few weeks I hacked makepkg to add this very feature, I didn't took
> time to test
> it exhaustively nor to propose it to the authors.

Why are we trying to resolve a problem that we've already solved through
discussion previously?

The idea was to provide a consistent set of PKGBUILDs with topological rebuilds
and updates. There is no reason to hack makepkg with post-install version
changes and other nastiness.

We should provide a full set of PKGBUILDs that specify dependencies via specific
versions (when necessary, which may be always). Topological updates will then
propagate down the dep chain as necessary. All topological updates will be
released simultaneously and thus the user updates all affected packages at once.

Wouldn't this solve the problem?

The idea that I originally proposed was to "abandon" the AUR in favor of our
own repository of PKGBUILDs and local source files (alongside a binary repo).
On the AUR, we have to worry about maintaining a monopoly of Haskell packages
for this to work (e.g. to avoid breaking others' packages and to make sure that
all of our deps are under our control). I think we should have a simple online
directory of the latest PKGBUILDs and local source files that people can
download just as they download from the AUR. All it needs is a simple layout
(e.g. "/pkgbuilds/{haskell-foo,haskell-bar,haskell-baz,etc}" and maybe some
JSON interface for building tools.

This seems far simpler than getting a patch into makepkg to enable us to kludge
our way through this. Maintenance of anything outside of that repo will be left
up to the respective maintainers. Our goal isn't to get everyone to cooperate,
it's to provide an internally consistent set of packages for the users.

I will of course help to provide tools for automatically building packages from
this PKGBUILD repo (bauerbill integration initially, then support in its
replacement when I have it, along with whatever other tools might be useful).


Now, to be less abstract, let's talk about some goals and code.

Our goals right now seem to be to provide the latest official version of the
Haskell Platform and in parallel provide the latest working set of all packages.

We should be able to generate a dependency graph to track versions for both of
these sets and use that for topological rebuilds. We then need update scripts
that bump versions, update the graph, then regenerate PKGBUILDs (and rebuild
binary packages) when necessary before pushing everything to our repo (source
and/or binary).

If someone can provide me a way to determine the versions that belong to these
sets then I can start working on something to create repo and handle the
topological rebuilds/PKGBUILD bumps. We can upload that on the kiwilight
server alongside the binary repo.*

If we really want to maintain the arch-haskell presence on the AUR then I
suggest that we get the separate PKGBUILD repo working as a proof-of-principle.
Once we have that, we could make an argument for re-establishing a monopoly of
haskell packages on the AUR. Really though, the only advantage that I see in
using the AUR is that it's familiar to many users. We can easily achieve
familiarity with our own repo, at least among Haskell users, through a few
announcement and user-friendly tools, which I believe we can provide.



/Xyne




* That gives me an idea... I'm going to ask Kaiting if we can have an
  arch-haskell account on the server so that we can share access to the repo
  and whatever else we want on there. It could be a good droppoint for
  collaboration on other things too. I'll post an update once I get a response.