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

On 2010/10/19 Magnus Therning wrote:

On Tue, Oct 19, 2010 at 13:31, Xyne wrote: [...]

...

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 agree with you about this.  However, this raises the question of how we make this is to happen.  Who do we have to convince?  What do we have to do?

I suggest we set up our infrastructure first: when everything is ready, we can think about changing how packages are managed in [extra] and [community]. However, I disagree with the possibility that [community] packages could depend on [arch-haskell], just like there is no way a [community] package can depend on a [multilib] package. I think there is no harm having a full [arch-haskell] repository that people can put at top of pacman.conf, so that it is used with higher priority than [extra] and [community]. So first we have a robust and tested system, and then we discuss about how it integrates with the mainstream package set. -- Rémy.