Re: [arch-haskell] ghc-6.10.2 in testing
Excerpts from Peter Hercek's message of Thu Apr 09 14:00:05 +0300 2009:
Vesa Kaihlavirta wrote:
But if we assume that unregister.sh files can contain only "ghc-pkg unregister" calls then there is no need to even call them. The new ghc will come with a new/pristine package.conf. Still I would like if you could save off a copy of the pristine package.conf when installing ghc. Then I could check in robust way what I installed on top of clean ghc. A postinstall step like "cd /usr/lib/ghc-<ver>; cp package.conf package.conf.asInstalled".
Yes, that's what I've wondered about too, actually. I like your suggestion. And we can use pacman's configuration file handling instead of rolling our own. 6.10.2-2 postponed then a bit more :) I hope I can get this out soon, because I'll be on vacation until the 19th, and away from my x86_64 box. --vk
Many packages in [community] remain to be rebuilt against the new ghc. Perhaps we should depend on specific ghc versions: that way pacman will enforce the dependencies: it won't really reduce the work required to upgrade ghc, but I think that it might be more clear that said installed libraries won't work. * On Monday, April 20 2009, Vesa Kaihlavirta wrote:
ghc-6.10.2-2 is in extra.
--vk _______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
On Fri, Apr 24, 2009 at 11:12:56PM -0400, Adam Vogt wrote:
Many packages in [community] remain to be rebuilt against the new ghc.
Perhaps we should depend on specific ghc versions: that way pacman will enforce the dependencies: it won't really reduce the work required to upgrade ghc, but I think that it might be more clear that said installed libraries won't work.
I agree. In fact, my packages in community already do this. --vk
vegai:
On Fri, Apr 24, 2009 at 11:12:56PM -0400, Adam Vogt wrote:
Many packages in [community] remain to be rebuilt against the new ghc.
Perhaps we should depend on specific ghc versions: that way pacman will enforce the dependencies: it won't really reduce the work required to upgrade ghc, but I think that it might be more clear that said installed libraries won't work.
I agree. In fact, my packages in community already do this.
That's an interesting idea. [community] is smaller than AUR, so it may be feasible to tag with the required GHC. I don't think this would help AUR, though. -- Don
* On Saturday, April 25 2009, Don Stewart wrote:
vegai:
On Fri, Apr 24, 2009 at 11:12:56PM -0400, Adam Vogt wrote:
Many packages in [community] remain to be rebuilt against the new ghc.
Perhaps we should depend on specific ghc versions: that way pacman will enforce the dependencies: it won't really reduce the work required to upgrade ghc, but I think that it might be more clear that said installed libraries won't work.
I agree. In fact, my packages in community already do this.
That's an interesting idea. [community] is smaller than AUR, so it may be feasible to tag with the required GHC.
Ok. Here is a simple way to do it by modifiying the package after the fact: #!/bin/sh ghcver=6.10.2 # we could get this from pacman tar xzf "$1" .PKGINFO mv .PKGINFO pkginfo sed "s/^depend = ghc*$/depend = ghc==$ghcver/" < pkginfo > .PKGINFO tar czf "$1" .PKGINFO rm .PKGINFO pkginfo Unfortunately, pacman does not let you specify a specific release version since different releases are unlikely to be binary compatible. Other than changing pacman in that respect (if it doesn't break or change anything else, I can't see there being any problems with that), we could add the release version to the ghc package version (ghc-6.10.2rel2-2), but that is sort of unpleasant.
I don't think this would help AUR, though.
Agreed. With the AUR this problem is much less serious, since those packages are usually installed right after being built (ie, what yaourt does). Another place to check the ghc version is in the register script which could easily contain the full ghc version that the package was built with. That won't affect how pacman chooses which versions to install however. Adam
participants (3)
-
Adam Vogt -
Don Stewart -
Vesa Kaihlavirta