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.