On Thu, Oct 20, 2011 at 14:29, Peter Hercek wrote:

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 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).

Indeed. I've planned to work on adding pkgrel handling to cblrepo, but haven't gotten that far yet. Currently these cases are caught iff the person updating habs uses cblrepo properly, this isn't ideal.

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.

That's a rather specialised use-case AFAIU. The ArchHaskell team only controls the [haskell] repo, so a group would only exist there. It's just as easy to install everything from a single repo using the output from `pacman -Sl haskell` then. For the use-case of installing all Haskell packages a group only be worthwhile if it existed in the official Arch repos as well.

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.

habs shouldn't contain any packages that are in community, but it needs to know about them (needs to know the exact version, and in the future the pkgrel too). This in order to put in proper dependencies.

Anyway my call to create haskell (or ghc) group was not only for [haskell] but also for community/extra.

The Arch devs on the list will have to weigh in on this. It does seem to be a slightly out-of-the-ordinary use of a group. /M -- Magnus Therning                      OpenPGP: 0xAB4DFBA4 email: magnus@therning.org   jabber: magnus@therning.org twitter: magthe               http://therning.org/magnus