[arch-haskell] How to determine whether a package is in or out in [haskell]?

Fabio Riga rifabio at gmail.com
Sat Oct 12 07:39:45 UTC 2013

Hi Magnus,

sorry for my late answer on this and for my bad English... I'll try to be
more clear.

IMHO, the ArchHaskell project should be a very big repository with most
up-to-date packages from hackage. Now, it seems to me that you are doing
all the work, so it's not possible for this project to grow (actually you
proposed to drop some packages!). It seems to me that the method you're
adopting doesn't allow a real help from others: some times ago I try to
help, run some update in cblrepo, build all the updates and pushed the
changed cblrepo.db file to you. I assume that you had to build all packages
again. And this is a waste of time.

My idea is to use cblrepo in another way: now cblrepo.db file has about 300
packages. We should split this file in 4 or 5 groups of packages, 1 group
(the main one) with common, more basic packages and the others divided
by category  (for example: net, dev, etc.). We should group the packages,
so that one group has dependencies only in itself or in main group. So
let's say, for instance, that you work on the main package and I take the
network. I will create a cblrepo db that *depends* on your: if there are
updates in the network, I'll do the updates, and send to you (or upload to
the server) the resulting packages; when there are changes in the main
you'll do your job, and I will bump packages that depends on the ones
updated by you. If I understand well, that's the way you deal with

So my cblrepo db will include packages belonging to your cblrepo as *
DistroPkg*. This will share the long compiling work between us. The
downside is that we *must* be in sync: you have to tell me witch package
you are updating and I can't wait long before update, or packages will be
broken. I would take the risk, anyway, there are already broken packages,
but that's depends on another problem, I will discuss this on the proper

A script should automate the process of finding, inserting and compiling
updates, i.e. should wrap cblrepo into something more easy. I'm working on


2011/11/14 Magnus Therning <magnus at therning.org>

> > why should we drop packages?  Unless we are running out of space on the
> > repository server we shouldn't. So I think we should find a solution to
> > decentralize the building process. So a build server could be okay. Is
> it a
> > problem to have a maintainer that check some packages, and not
> everything?
> Sure, we could use a build server. There's a standing request for
> anyone to step up with an offer of a system that we can use.  Ideally
> with a web interface so we can submit source packages, together with a
> build list, and then just check in to get the results later on. In the
> meantime however, we're stuck with building things on whatever systems
> we have access to.
> I'm not sure I understand your question about maintainers, but I'll
> take a stab at answering anyway. Let me know if I got you all wrong :)

Sorry. I'll try to improve  my English! :-)

> Hackage moves very quickly, and it's very common that updating a
> single package requires that a few others are updated as well. Due to
> the nature of the code that GHC spits out we also need to bump the
> release of all packages that depend on an updated package. The end
> result is that it's very rare that I can update a single package, and
> I don't I've ever been able to build just a single package due to an
> update. Given this I don't see much value in having maintainers for
> subsets of ArchHaskell.
> > The main maintainer should only put everything together, maybe
> periodically,
> > so the others know when to submit updates and when to wait for the next
> one.
> > Are you sure this will be more painful than build everything by your own
> on
> > your laptop?
> I don't understand what you mean here, would you mind giving an example?
> /M
> --
> Magnus Therning                      OpenPGP: 0xAB4DFBA4
> email: magnus at therning.org   jabber: magnus at therning.org
> twitter: magthe               http://therning.org/magnus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/arch-haskell/attachments/20131012/765c45b4/attachment.html>

More information about the arch-haskell mailing list