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

Peter Hercek phercek at gmail.com
Thu Oct 20 14:31:37 CEST 2011

Forgot to send this to group:

On 10/20/2011 01:30 PM, Magnus Therning wrote:
> On Thu, Oct 20, 2011 at 13:03, Peter Hercek<phercek at gmail.com>  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
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.

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

Thanks for your arch-haskell work,

More information about the arch-haskell mailing list