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

On Thu, Oct 20, 2011 at 13:03, Peter Hercek wrote:

...

Hi,

This is a call to create pacman group with name haskell (or ghc or something similar). All packages which depend on ghc would belong to the group. The reason why I would like to see this is to allow disabling update of any ghc dependency easily in pacman.conf. It would be cool if something like "IgnoreGroup = haskell" in /etc/pacman.conf would postpone update of any ghc dependency. Normally non-haskell packages do not need this but since haskell has no backward binary compatibility it can be really useful sometimes. This situation is the reason for having specific versions in all dependencies. Is there a scenario where this wouldn't be enough? Yes, I like the fact we have specific versions in dependencies ... including pkgrel which is not there always. If I understand Simon Marlow correctly here http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/20002

...

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

Forgot to send this to group: On 10/20/2011 01:30 PM, Magnus Therning wrote: then it is not sure that we will have the same ABI even when compiling exactly the same code (with the same compiler). My practical experience is that when one compiles the same code with the same compiler then the result is almost always the same. Anyway, pkgrel change can also mean different compiling options which definitely can change ABI. So I think pkgrel should be in all dependencies too. In fact pacman dependencies are dependencies between binary packages so they should be exact (contrary to source code dependencies in cabal). AFAIK, exact pacman dependencies will detect all the problems when installing a binary package. But detection and ease of you is a bit different. I typically have a bit modified ghc itself (mostly to get collored stderr which interleaves with stdout correctly and some other details). So it is not uncommon I want to postpone ghc update and that means all haskell related update. For such a case I want to ignore everything haskell related during updates. I could put in pacman.conf only "IngnorePkg=ghc" but then pacman will spit a ton of warnings about what other packages cannot be updated too and whether I'm aware of it. I happened to have sometimes my own changes to gtk2hs too. This would be another case when I would like to postpone any haskell related update. For this e.g. "IgnoreGroup=haskell" would be really useful. So who can use this group? AFAIK only people who sometimes have modified haskell packages on their systems or because of their own development want to postpone haskell updates a bit. Well and possibly people who want to install everything haskell related as I mentioned below. 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. Thanks for your arch-haskell work, Peter.