Hey, The new ghc is just a simple verbump at least for now. It doesn't try to do anything intelligent for your cabalized or cabal2arch packages, so all those do break. I'm interested in ideas how to mitigate these issues... now, it seems to me that they cannot very much, and the most we can do is unregister everything prior to upgrading and informing the user of this. Also, none of the community packages are built against this yet, so those will break as well. --vk
Hi, What is the reason for having network.patch in the svn entries of the package. It does not seem to be used. Peter. Vesa Kaihlavirta wrote:
Hey,
The new ghc is just a simple verbump at least for now. It doesn't try to do anything intelligent for your cabalized or cabal2arch packages, so all those do break.
I'm interested in ideas how to mitigate these issues... now, it seems to me that they cannot very much, and the most we can do is unregister everything prior to upgrading and informing the user of this.
Also, none of the community packages are built against this yet, so those will break as well.
--vk _______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
Should be removed. phercek:
Hi,
What is the reason for having network.patch in the svn entries of the package. It does not seem to be used.
Peter.
Vesa Kaihlavirta wrote:
Hey,
The new ghc is just a simple verbump at least for now. It doesn't try to do anything intelligent for your cabalized or cabal2arch packages, so all those do break.
I'm interested in ideas how to mitigate these issues... now, it seems to me that they cannot very much, and the most we can do is unregister everything prior to upgrading and informing the user of this.
Also, none of the community packages are built against this yet, so those will break as well.
--vk _______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
_______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
vegai:
Hey,
The new ghc is just a simple verbump at least for now. It doesn't try to do anything intelligent for your cabalized or cabal2arch packages, so all those do break.
"break" in the sense that they're now registered but won't have an appropriate compiler installed.
I'm interested in ideas how to mitigate these issues... now, it seems to me that they cannot very much, and the most we can do is unregister everything prior to upgrading and informing the user of this.
Right. If we could at least list the names (and commands to reinstall ) packages that are about to break (all haskell-* on the system), that might be nice. Essentially, something like: "WARNING: the following packages will need to be reinstalled: pacman -Qs haskell- local/haskell-xauth 0.1-1 A binding to the X11 authentication library local/haskell-xcb-types 0.5.1.1-1 Parses XML files used by the XCB project local/haskell-xhtml 3000.2.0.1-1 An XHTML combinator library local/haskell-xml 1.3.4-1 A simple XML library. local/haskell-xml-basic 0.0.1-1 Basics for XML/HTML representation and processing local/haskell-yogurt 0.3-1 A MUD client library local/haskell-zip-archive 0.1.1.3-1 Library for creating and modifying zip archives. local/haskell-zlib 0.5.0.0-1 Compression and decompression in the gzip and zlib formats local/haskell-zoneinfo 0.3-1 ZoneInfo library. ... etc... ?
Also, none of the community packages are built against this yet, so those will break as well.
OK.
Don Stewart wrote:
vegai:
I'm interested in ideas how to mitigate these issues... now, it seems to me that they cannot very much, and the most we can do is unregister everything prior to upgrading and informing the user of this.
Right.
If we could at least list the names (and commands to reinstall ) packages that are about to break (all haskell-* on the system), that might be nice.
Essentially, something like:
"WARNING: the following packages will need to be reinstalled: pacman -Qs haskell
If I understand it correctly all libraries need to be reinstalled and executables can stay. Is naming convention designed in such a way that "pacman -Qs haskell" should get the same result as "pacman -Qi ghc |grep '^Required By'"? Peter.
Excerpts from Peter Hercek's message of Wed Apr 08 09:17:31 +0300 2009:
Don Stewart wrote:
If I understand it correctly all libraries need to be reinstalled and executables can stay. Is naming convention designed in such a way that "pacman -Qs haskell" should get the same result as "pacman -Qi ghc |grep '^Required By'"?
Not quite. How about `ls /usr/share/haskell/`? All cabal2arch packages add a directory there. --vk
Vesa Kaihlavirta wrote:
Excerpts from Peter Hercek's message of Wed Apr 08 09:17:31 +0300 2009:
Don Stewart wrote:
If I understand it correctly all libraries need to be reinstalled and executables can stay. Is naming convention designed in such a way that "pacman -Qs haskell" should get the same result as "pacman -Qi ghc |grep '^Required By'"?
Not quite. How about `ls /usr/share/haskell/`? All cabal2arch packages add a directory there
Ok, so the most safe way is taking "ghc-pkg list" except the packages distributed with ghc. This means a "database" of packages which were distributed with ghc (for each of its versions which existed on archlinux) would need to be maintained. For example the list of package.conf files from previous versions of ghc is such a database. But we really need only the pristine (as installed) package.conf for the ghc version we are going to replace. What about adding some commands to ghc installation which would store-off a copy of package.conf file. Then we could write a script which tells what needs to be recompiled with a new ghc version. The second best is probably to take "ls /usr/share/haskell" since almost all haskell packages are distributed with cabal. Peter.
participants (4)
-
Don Stewart -
Peter Hercek -
Vesa Kaihlavirta -
Vesa Kaihlavirta