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

[Magnus Therning]

On Thu, Oct 20, 2011 at 14:29, Peter Hercek <phercek at gmail.com> 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 at therning.org   jabber: magnus at therning.org
twitter: magthe               http://therning.org/magnus