
On Tue, Oct 19, 2010 at 14:05, Rémy Oudompheng
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.
Well, I'm still completely set on washing my hands of AUR when it comes to Haskell packages, at least in the long term.
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.
Sure, but that brings back the biggest of issues with the binary-packages-plan: online storage. I personally don't have enough online storage and bandwidth to put up a repository and share it widely. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus@therning.org Jabber: magnus@therning.org http://therning.org/magnus identi.ca|twitter: magthe