On Sun, Nov 13, 2011 at 18:11, Fabio Riga <rifabio at gmail.com> wrote:
> Hello,
> 2011/11/12 Magnus Therning <magnus at therning.org>
>>>> It would be excellent if more people could work on keeping [haskell]
>> up-to-date :)
>>>> However, splitting updating the database and the building of packages
>> is likely to be a bit painful. So far my experience is that updating
>> packages to a buildable state often requires a few iterations of
>> modifying patch files and attempting builds. If each such iteration
>> requires communication it's likely to drag out quite a bit. The ideal
>> would be a build server really.
>>>> /M
>> 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 :)
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