[arch-dev-public] [Draft] - News announcement for GHC 7.8.2
Hey all, I would like feedback on this news announcement. Please bring up any issues you have with this post. Title: GHC 7.8.2 requires user intervention and brings changes. Content: The package haskell-transformers was previously a separate package but is now provided with ghc 7.8.2. Since ghc 7.8.2 does not replace haskell-transformers 0.3.0.0, the user must run the following command prior to upgrading their packages: pacman -Rcs haskell-transformers Changes that come with the release include: 1) Moving every package that is not ghc or cabal-install to [community]. This will allow better support of the core common haskell libraries since I do not actually use these packages due to cabal-install. 2) The valid paths that a user can take to install packages are the following: a) Using cabal-install to install haskell packages. This allows the user to access every haskell package in hackage. The problem is that you are now using packages that are managed outside of pacman. This is usually the best option if you are developing any haskell applications due to the new sandboxing that cabal-install 1.18 has introduced. b) Using pacman to install haskell packages. This allows the user to have access to a small subset of hackage packages which are known to work on archlinux and are usually good enough for non haskell developers. Note: These 2 paths should be considered mutually exclusive.
On 2014-04-28 18:55 -0700 Thomas Dziedzic wrote:
The package haskell-transformers was previously a separate package but is now provided with ghc 7.8.2. Since ghc 7.8.2 does not replace haskell-transformers 0.3.0.0, the user must run the following command prior to upgrading their packages:
pacman -Rcs haskell-transformers
That will likely remove several explicitly installed packages for many users. You should instruct them to first make a list of these and then re-install them afterwards. Incidentally, my pkg-topological_reinstall [1] is useful in this case but I understand if you are hesitant to appear to endorse it in an official announcement.
2) The valid paths that a user can take to install packages are the following:
a) Using cabal-install to install haskell packages. This allows the user to access every haskell package in hackage. The problem is that you are now using packages that are managed outside of pacman. This is usually the best option if you are developing any haskell applications due to the new sandboxing that cabal-install 1.18 has introduced.
b) Using pacman to install haskell packages. This allows the user to have access to a small subset of hackage packages which are known to work on archlinux and are usually good enough for non haskell developers.
Note: These 2 paths should be considered mutually exclusive.
I think you should mention Arch Haskell and [haskell-core]. You can stress that the project is not officially endorsed but it has been maintained reliably for years now with no signs of disappearing so it should be considered a viable option as well. It is truly a great resource for Haskell users on Arch. [1] http://xyne.archlinux.ca/projects/pkg_scripts/#help-message-pkg-topological_...
Thanks Xyne, 1) I'm not opposed to recommending a tool in the aur if it greatly simplifies a problem. I checked out your pkg-topological_reinstall script and although it looks good for its purpose, I'm afraid that none of the files generated solve the issue of removing haskell-transformers, upgrading ghc, then installing the missing packages. I will just mention that the user should reinstall the packages the user removed with pacman -Rcs haskell-transformers. 2) Good point, I forgot about arch-haskell when I was writing this email. I will definitely mention them as an unofficial repo. Here is the updated post: Title: GHC 7.8.2 requires user intervention and brings changes. Content: The package haskell-transformers was previously a separate package but is now provided with ghc 7.8.2. Since ghc 7.8.2 does not replace haskell-transformers 0.3.0.0, the user must run the following command prior to upgrading the packages: pacman -Rcs haskell-transformers Don't forget to reinstall the packages that got removed from the above command after upgrading ghc. Changes that come with the release include: 1) Moving every package that is not ghc or cabal-install to [community]. This will allow better support of the core common haskell libraries since I do not actually use these packages due to cabal-install. 2) The valid paths that a user can take to install packages are the following: a) Using cabal-install to install haskell packages. This allows the user to access every haskell package in hackage. The problem is that you are now using packages that are managed outside of pacman. This is usually the best option if you are developing any haskell applications due to the new sandboxing that cabal-install 1.18 has introduced. b) Using pacman to install haskell packages. This allows the user to have access to a small subset of hackage packages which are known to work on archlinux and are usually good enough for non haskell developers. c) Using an unofficial repository called Arch Haskell. You could find more information about the repository at the following page: https://github.com/archhaskell/habs/blob/master/README.md Note: These 3 paths should be considered mutually exclusive.
[2014-04-28 18:55:32 -0700] Thomas Dziedzic:
Hey all, I would like feedback on this news announcement.
There go my two cents...
GHC 7.8.2 requires user intervention and brings changes. ^^^^^^^^^^^^^^ Any chance you could be more specific? May I suggest something like "Upgrading to, and managing Haskell packages with GHC 7.8.2"?
Since ghc 7.8.2 does not replace haskell-transformers 0.3.0.0
Simple question: why isn't that the case? The rest of the news announcement looks good to me. Cheers. -- Gaetan
1) I'm not opposed to recommending a tool in the aur if it greatly simplifies a problem. I checked out your pkg-topological_reinstall script and although it looks good for its purpose, I'm afraid that none of the files generated solve the issue of removing haskell-transformers, upgrading ghc, then installing the missing packages.
Just for clarification, the second command in the generated "reinstall.sh" script should re-install all explicitly installed packages that depend on ghc. It could be run after "pacman -Rsc haskell-transformers" and the upgrade to re-install any packages that were hit by the cascade. It's not a direct solution to the problem but it can be easily adapted to become one.
On Tue, Apr 29, 2014 at 11:23 PM, Gaetan Bisson <bisson@archlinux.org>wrote:
GHC 7.8.2 requires user intervention and brings changes. ^^^^^^^^^^^^^^ Any chance you could be more specific? May I suggest something like "Upgrading to, and managing Haskell packages with GHC 7.8.2"?
Thanks for this, I will use this title instead
Since ghc 7.8.2 does not replace haskell-transformers 0.3.0.0
Simple question: why isn't that the case?
The ghc in [testing] provides=('haskell-transformers=0.3.0.0') and replaces=('haskell-transformers<0.3.0.0') but in repos, it is at 0.3.0.0 so this replaces is not enough. I caught this replaces only after everything was built and moved to [testing]. Changing the replaces to replaces=('haskell-transformers') would require recompiling every package that was recompiled as part of the todo. updated Draft: Title: Upgrading to, and managing Haskell packages with GHC 7.8.2 Content: The package haskell-transformers was previously a separate package but is now provided with ghc 7.8.2. Since ghc 7.8.2 does not replace haskell-transformers 0.3.0.0, the user must run the following command prior to upgrading the packages: pacman -Rcs haskell-transformers Don't forget to reinstall the packages that got removed from the above command after upgrading ghc. Changes that come with the release include: 1) Moving every package that is not ghc or cabal-install to [community]. This will allow better support of the core common haskell libraries since I do not actually use these packages due to cabal-install. 2) The valid paths that a user can take to install packages are the following: a) Using cabal-install to install haskell packages. This allows the user to access every haskell package in hackage. The problem is that you are now using packages that are managed outside of pacman. This is usually the best option if you are developing any haskell applications due to the new sandboxing that cabal-install 1.18 has introduced. b) Using pacman to install haskell packages. This allows the user to have access to a small subset of hackage packages which are known to work on archlinux and are usually good enough for non haskell developers. c) Using an unofficial repository called Arch Haskell. You could find more information about the repository at the following page: https://github.com/archhaskell/habs/blob/master/README.md
On Wed, Apr 30, 2014 at 12:12 PM, Xyne <xyne@archlinux.ca> wrote:
Just for clarification, the second command in the generated "reinstall.sh" script should re-install all explicitly installed packages that depend on ghc. It could be run after "pacman -Rsc haskell-transformers" and the upgrade to re-install any packages that were hit by the cascade. It's not a direct solution to the problem but it can be easily adapted to become one.
I saw the reinstall.sh script and I was thinking that it might be too much to explain to the user that they would have to install a package, run a command, modify a script, then run that script.
[2014-04-30 18:05:15 -0700] Thomas Dziedzic:
Changing the replaces to replaces=('haskell-transformers') would require recompiling every package that was recompiled as part of the todo.
Really? Perhaps I'm missing something, but couldn't we just manually edit the .PKGINFO from inside the tarball and let the rest as-is? -- Gaetan
On Wed, Apr 30, 2014 at 8:50 PM, Gaetan Bisson <bisson@archlinux.org> wrote:
Really? Perhaps I'm missing something, but couldn't we just manually edit the .PKGINFO from inside the tarball and let the rest as-is?
Oh, hmm... I never gave that any consideration. I've been avoiding editing PKGINFO files up until now, but if it fixes it and I could push a changed package to [testing] without affecting the move to [extra] that would be awesome! What are the exact steps to modifying a package that is already in repos?
On Wed, 30 Apr 2014 21:02:08 -0700 Thomas Dziedzic <gostrc@gmail.com> wrote:
On Wed, Apr 30, 2014 at 8:50 PM, Gaetan Bisson <bisson@archlinux.org> wrote:
Really? Perhaps I'm missing something, but couldn't we just manually edit the .PKGINFO from inside the tarball and let the rest as-is?
Oh, hmm... I never gave that any consideration. I've been avoiding editing PKGINFO files up until now, but if it fixes it and I could push a changed package to [testing] without affecting the move to [extra] that would be awesome!
What are the exact steps to modifying a package that is already in repos?
Extract it, edit the pkginfo, repackage with the same cmd makepkg uses. Since it has been released already you should also increase the pkgrel and make sure to also update the pkgbuild. Then simply use testingpkg to push it. Don't use vim to edit the tarball "directly" since that will move the pkginfo at the end of the package making pacman slower. (tar tf $file | head; should list the pkginfo as one of the first entries)
On Thursday, May 01, 2014 10:51:57 Florian Pritz wrote:
you should also increase the pkgrel
There are some packages depending explicitly on the specific pkgrel (7.8.2-2), such as: https://www.archlinux.org/packages/community-testing/i686/haskell-haskeline/ I'm not sure if adding a "provides" item will fix this. Regards, Felix Yan
Thomas Dziedzic wrote:
I saw the reinstall.sh script and I was thinking that it might be too much to explain to the user that they would have to install a package, run a command, modify a script, then run that script.
Maybe, but Archers are supposed to be able to figure these things out. ;) Anyway, I only wanted to clarify, not change your mind about mentioning it. Perhaps I'll add a script just to list explicitly installed packages that depend on a given package (directly or indirectly).
Xyne wrote:
Perhaps I'll add a script just to list explicitly installed packages that depend on a given package (directly or indirectly).
done http://xyne.archlinux.ca/projects/pkg_scripts/#help-message-pkg-list_depende...
[2014-05-01 16:55:49 +0800] Felix Yan:
There are some packages depending explicitly on the specific pkgrel (7.8.2-2), such as: https://www.archlinux.org/packages/community-testing/i686/haskell-haskeline/
I'm not sure if adding a "provides" item will fix this.
Why not? -- Gaetan
On Thursday, May 01, 2014 19:05:09 Gaetan Bisson wrote:
[2014-05-01 16:55:49 +0800] Felix Yan:
There are some packages depending explicitly on the specific pkgrel (7.8.2-2), such as: https://www.archlinux.org/packages/community-testing/i686/haskell-haskeli ne/
I'm not sure if adding a "provides" item will fix this.
Why not?
Then it's the way to go :P I didn't do this before so I was not very sure... Regards, Felix Yan
On Thu, May 1, 2014 at 1:51 AM, Florian Pritz <bluewind@xinu.at> wrote:
Extract it, edit the pkginfo, repackage with the same cmd makepkg uses.
Since it has been released already you should also increase the pkgrel and make sure to also update the pkgbuild. Then simply use testingpkg to push it.
Don't use vim to edit the tarball "directly" since that will move the pkginfo at the end of the package making pacman slower. (tar tf $file | head; should list the pkginfo as one of the first entries)
Thanks! This worked beautifully. I tested the update using a custom repo and it removed the transformers package along with upgrading the existing packages. Also, adding a provides ghc=7.8.2-2 saved a whole lot of time. You guys are awesome :) updated draft: Title: Managing Haskell packages with GHC 7.8.2 Content: Changes that come with the release include: 1) Moving every package that is not ghc or cabal-install to [community]. This will allow better support of the core common haskell libraries since I do not actually use these packages due to cabal-install. 2) The valid paths that a user can take to install packages are the following: a) Using cabal-install to install haskell packages. This allows the user to access every haskell package in hackage. The problem is that you are now using packages that are managed outside of pacman. This is usually the best option if you are developing any haskell applications due to the new sandboxing that cabal-install 1.18 has introduced. b) Using pacman to install haskell packages. This allows the user to have access to a small subset of hackage packages which are known to work on archlinux and are usually good enough for non haskell developers. c) Using an unofficial repository called Arch Haskell. You could find more information about the repository at the following page: https://github.com/archhaskell/habs/blob/master/README.md
[2014-05-01 21:46:43 -0700] Thomas Dziedzic:
Thanks! This worked beautifully. I tested the update using a custom repo and it removed the transformers package along with upgrading the existing packages. Also, adding a provides ghc=7.8.2-2 saved a whole lot of time.
I'm glad to hear that!
Title: Managing Haskell packages with GHC 7.8.2
Content: Changes that come with the release include: 1) Moving every package that is not ghc or cabal-install to [community]. This will allow better support of the core common haskell libraries since I do not actually use these packages due to cabal-install.
2) The valid paths that a user can take to install packages are the following:
a) Using cabal-install to install haskell packages. This allows the user to access every haskell package in hackage. The problem is that you are now using packages that are managed outside of pacman. This is usually the best option if you are developing any haskell applications due to the new sandboxing that cabal-install 1.18 has introduced.
b) Using pacman to install haskell packages. This allows the user to have access to a small subset of hackage packages which are known to work on archlinux and are usually good enough for non haskell developers.
c) Using an unofficial repository called Arch Haskell. You could find more information about the repository at the following page: https://github.com/archhaskell/habs/blob/master/README.md
Looks good to me. Cheers. -- Gaetan
participants (5)
-
Felix Yan
-
Florian Pritz
-
Gaetan Bisson
-
Thomas Dziedzic
-
Xyne