[arch-haskell] creation of haskell (or ghc) pacman group

[Peter Hercek]

On 10/20/2011 02:31 PM, Peter Hercek wrote:
>
>>> If somebody installs everything from haskell, then this would also 
>>> allow
>>> installing everything at once (using the group name). Although for 
>>> this to
>>> work we might need first to make sure there are no duplicates between
>>> extra/community/haskell repositories. Not sure how trying to install 
>>> whole
>>> group would behave when it hits duplicates (like e.g. gtk2hs-gtk in
>>> community and haskell-gtk2hs-gtk in haskell (well, the one in 
>>> haskell is
>>> more useful since it provides glade bindings too)).
>> The goal is to have no such overlap. The problem is to recognise when
>> such an overlap occurs. There are two situations that ArchHaskell
>> needs to notice:
>>
>> 1. A Haskell package in core/extra/community is updated to a new version
>> 2. A Haskell package is added to core/extra/community
>>
>> Is there some way of (semi-)automating this already?
> I do not have any tool for this. It would need to follow history in 
> core/extra/community which (in the worst case) can be obtained from 
> the web interface or the git of package definitions. I hope there is a 
> better way since this will not catch binary recompiles. But maybe 
> there is a different way around it. We could just ignore e.g. 
> community (if we have all comunity packages in habs), name packages 
> the same (or maybe putting the community package names in provides is 
> enough?) and put [haskell] source before [community] source in 
> pacman.conf. There should be coordination between 
> extra/community/haskell package sources. Who maintains extra and 
> community? They should know more.
>
> Anyway my call to create haskell (or ghc) group was not only for 
> [haskell] but also for community/extra.

If there is no other channel for comunication between maintainers of 
different repositories then the best may be to follow what did change in 
core/extra/comunity package database. For this the group may be useful 
too, but can be (better?) done based on dependency on ghc. Again this 
would be a pull approach. A push approach (get notified when something 
needs to be done) would be better.