[arch-haskell] creation of haskell (or ghc) pacman group
phercek at gmail.com
Thu Oct 20 15:05:34 CEST 2011
On 10/20/2011 02:31 PM, Peter Hercek wrote:
>>> If somebody installs everything from haskell, then this would also
>>> 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
>>> 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.
More information about the arch-haskell