[arch-haskell] How to update packages in extra?

[Xyne]

Magnus Therning wrote:

> > I also volunteer to help for [extra] : if we ever have a binary
> > repository for arch-haskell, I suggest we only keep in
> > [extra]/[community] the needed libraries to build xmonad and other
> > popular Haskell programs.
> 
> I think it's worth thinking a bit about how to organise having popular
> Haskell programs in [extra] and [community].  And how to harmoniously
> have a [archhaskell] repository.
> 
> For instance:
> • what do we do with Haskell Platform?  (several of the packages in HP
> are already in [extra]/[community], but I don't think all are)
> • how do we deal with updates that trigger re-compilation across
> repositories?  (I often bump into haskell-http it seems, some package
> foo is compiled against one version, another package bar is compiled
> against another, and then I get scary messages from GHC when I try to
> compile baz which relies on both foo and bar)
> 
> I suspect there are no easy solutions to this particular problem.
> 
> /M

[edit]
Below I come to the conclusion that a different approach is better, but
I have left the beginning here to make my train of thought clear.
[/edit]

* Topological Rebuilds Spanning Multiple Repos
  This is not an issue as we only need to worry about [extra] and [community]
  (see comments about AUR and [arch-haskell] repo below).

  Topological rebuilds can be pushed to both [extra] and [community]
  simultaneously. If arch-haskell manages the full topological set then this is
  not an issue.

  The more likely scenario is that others outside of arch-haskell will maintain
  packages that depend on Haskell packages (probably in [community]... we
  should be able to adopt everything in [extra]).

  We could:
  - adopt an official upgrade policy (including tools) and leave it up to others
    to keep up with us... this may cause issues though

  - receive permission from other maintainers to rebuild their packages as
    necessary (it's possible to update others' packages), e.g. all haskell
    packages in [extra] and [community] could be rebuilt automatically as
    needed

   - request a monopoly on Haskell packages to avoid such considerations and to
     control the inclusion of Haskell packages in [extra] and [community]


  The AUR will be left to the end users who build their own packages and tools
  such as bauerbill can be updated to simplify the process.

  I think [extra] packages need to be signed off though, unlike [community]
  packages, which might make scripted rebuilds more painful than they need to
  be.

  We would have to look into the procedure of using the corresponding testing
  repos when necessary.


The reason that I suggested a separate [arch-haskell] repo in the first place
was to avoid all of these considerations. I still think it might be much simpler
to remove all Haskell packages from [extra] and most from [community] and
maintain them in a separate repo. If it were official like the [multilib] repo
then it could be enabled by default in pacman.conf.

Basically any package that would need to be part of a topological rebuild would
be in [arch-haskell]. This would exclude some packages from [community] but
this would have no effect on the end user as it would be enabled by default in
pacman.conf and just as accessible. [community] and [arch-haskell] could also
be codependent, i.e. deps from one could be in the other, as both could be
expected to be enabled by default.

The more I think about it, the more I am convinced that this is the optimal
approach. This guarantees that we can maintain internal consistency with
topological (and maybe even automatic) rebuilds and we do not need to worry
about others remaining synchronized with our build cycle. It keeps everything
in one place and would also gain the benefits of being mirrored with the rest
of the official repos.



I have more thoughts concerning parallel repos for different subsets of package
versions, but I'll leave that for another post to avoid distraction from the
current topic.

Regards,
Xyne