Alessandro Pezzoni wrote:

Hi, when I asked about it, Magnus Therning explained why they were removed [1]. As this seems to affect only ghc, it looks to me like their only reason to be kept there would be to simplify making packages with PKGBUILDs generated by cabal2arch (such as most of those on the AUR), which is deprecated in favour of cblrepo. Is there another reason to keep them?

Alessandro

1: http://article.gmane.org/gmane.comp.lang.haskell.arch-linux/1335

Let's say that I want to create some private Haskell packages. These will depend on certain modules and/or packages. Without proper provides arrays, I need to keep track of what is provided by ghc & co. myself and update my dependency arrays whenever it changes. This is not practical. Automatically populating the array should not be an issue. It just provides additional information for others without affecting the internal consistency of [haskell]. Unless it's really hard to generate the array itself, I see only advantages in doing so and I hope that it will be re-instated. Regards, Xyne Bah, my first reply got sent off-list. Please try to avoid sending replies directly to me. Thanks.

Alessandro Pezzoni wrote:

You could/should create it with the cblrepo database in habs. This way you would manage the other dependencies, too.

That approach is probably optimal, but not everyone will use cblrepo. As it's easy to add, it is better to include the necessary information for "traditional" Pacman packaging. That way everyone is happy. The Haskell guidelines can always be updated to strongly recommend using cblrepo (if they don't already).

Maybe I have to make clear that I'm not arguing against one approach or the other, as they seem almost equivalent to me. The only actual benefit I see from the current approach, as previously I found a bit cumbersome to find out which versions of which packages were provided by the ghc package (only way I found was looking directly in the ABS PKGBUILD, but maybe there is a simpler one).

You can just check "pacman -Si ghc" or "pacman -Qi ghc" to see what is provided. You could also use e.g. pyalpm to write a very simple script to do it as well, or even write a Bash script to parse the pacman database files. I don't mean that those approaches would be better. I only mention them as alternatives to checking ABS. Anyway, Magnus has agreed to re-insert the provides array, so this is once again just a matter of user choice, which should make everyone happy. ;)

On 03/08/2012 10:10 AM, Magnus Therning wrote:

Good reason for re-adding the provides array. I'll make sure it's added the next time I re-build the ghc package. As Alessandro pointed out it's fairly easy to auto-generate it from the contents of 'cblrepo.db'.

A bit related is the separate group for [haskell] packages. Provided that ghc will be located where it is in the habs tree, then we could modify groups array for ghc like this: groups=('fromHaskellRepo') directly in the PKGBUILD file of the ghc package. When cblrepo would generate any PKGBUILD file, it would just add the groups variable so that it is the same as in the ghc PKGBUILD file. Ghc's PKGBUILD file location would be taken relative from dbFile location. Does it sound correct? It would be cool if community/extra could do something similar but with a **different** group name of course. Peter.