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

[Rémy Oudompheng]

On 2010/10/19 Magnus Therning <magnus at therning.org> wrote:
> On Tue, Oct 19, 2010 at 13:31, Xyne <xyne at archlinux.ca> 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.