[arch-general] Does ArchHaskell still have purpose?
Hi all, Well, the subject line says it all really. Does ArchHaskell still have a role in the Arch world? These are the reasons for asking this at this point: - the Haskell packages in [community] now number more than 400 and there is considerable overlap with ArchHaskell (unfortunately it's not a superset, not yet anyway) - the Haskell packages in [community] also seem to be well maintained and to receive timely updates, - the build-tool and development-tool situation for Haskell has improved considerably over the last few years, between `stack` and `cabal` coupled with improvements to `ghci` and introduction of `ghc-mod`, `intero` and `hsdev` I feel that Haskell development now should be carried out without system-wide installation of libs. In particular the last point means that I personally haven't had `ghc` installed via a package for the last couple of months. /M -- Magnus Therning OpenPGP: 0x927912051716CE39 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Never be afraid to try something new. Remember, amateurs built the ark; professionals built the Titanic. — Anonymous
On Mon, 2017-01-09 at 00:26 +0100, Magnus Therning wrote:
Hi all,
Well, the subject line says it all really. Does ArchHaskell still have a role in the Arch world?
Thanks Magnus for raising this topic. I actually have a few questions for the maintener of Haskell in [community] (Felix): 1. How do you manage dependencies and rebuilds of Haskell packages without using cblrepo? 2. Shouldn't you track also Cabal's metadata revisions? Thanks, Nicola
On 01/09/2017 07:26 AM, Magnus Therning wrote:
Well, the subject line says it all really. Does ArchHaskell still have a role in the Arch world?
Actually I am planning to make everything dynamic-linked in next GHC release, and kill all static libraries in the packages. This way haskell software will be one step closer to follow Arch packaging guidelines. The ArchHaskell packages, IMHO, will be more suited for Haskell development after the change. But as you mentioned, if system-wide packages are no longer a need for development, the need for two set of packages is also gone. On 01/09/2017 06:23 PM, Nicola Squartini via arch-general wrote:
1. How do you manage dependencies and rebuilds of Haskell packages without using cblrepo?
I still try to use cblrepo to track dependency versions, I just don't use it to generate PKGBUILDs directly.
2. Shouldn't you track also Cabal's metadata revisions?
The metadata updates are mostly about dependency versions and bounds, so I usually update that directly in the PKGBUILD instead. Please correct me if I'm wrong here, though. -- Regards, Felix Yan
Felix Yan
On 01/09/2017 07:26 AM, Magnus Therning wrote:
Well, the subject line says it all really. Does ArchHaskell still have a role in the Arch world?
Actually I am planning to make everything dynamic-linked in next GHC release, and kill all static libraries in the packages. This way haskell software will be one step closer to follow Arch packaging guidelines. The ArchHaskell packages, IMHO, will be more suited for Haskell development after the change.
But as you mentioned, if system-wide packages are no longer a need for development, the need for two set of packages is also gone.
Indeed! :)
On 01/09/2017 06:23 PM, Nicola Squartini via arch-general wrote:
1. How do you manage dependencies and rebuilds of Haskell packages without using cblrepo?
I still try to use cblrepo to track dependency versions, I just don't use it to generate PKGBUILDs directly.
I *love* hearing that it's being used. I'm just throwing this out there... if ArchHaskell goes the way of the dodo I'd be more than happy to continue working on cblrepo, and make it more suitable for your use case.
2. Shouldn't you track also Cabal's metadata revisions?
The metadata updates are mostly about dependency versions and bounds, so I usually update that directly in the PKGBUILD instead. Please correct me if I'm wrong here, though.
That is true, I think there is a document somewhere describing what kind of edits to metadata that is allowed via Hackage. Since cblrepo keeps track of ranges of dependencies itself I've found cases where it's really useful to pull xrevs into its database (cblrepo.db). However, this doesn't really mean that one has to release a new package on a new xrev (essentially tell pacman about the change to dependencies). If one is willing to move this knowledge from cblrepo to pacman in some other way (I'm guessing you're doing it manually, Felix) then that's fine. I'm just too lazy to do that ;) /M -- Magnus Therning OpenPGP: 0x927912051716CE39 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus As far as the laws of mathematics refer to reality, they are not certain, and as far as they are certain, they do not refer to reality. — Albert Einstein
On 01/09/2017 09:45 PM, Magnus Therning wrote:
I still try to use cblrepo to track dependency versions, I just don't use it to generate PKGBUILDs directly.
I *love* hearing that it's being used. I'm just throwing this out there... if ArchHaskell goes the way of the dodo I'd be more than happy to continue working on cblrepo, and make it more suitable for your use case.
That would be awesome, thanks! I'll open some discussion as cblrepo issues soon. -- Regards, Felix Yan
On 01/09/2017 06:23 PM, Nicola Squartini via arch-general wrote:
1. How do you manage dependencies and rebuilds of Haskell packages without using cblrepo?
I still try to use cblrepo to track dependency versions, I just don't use it to generate PKGBUILDs directly.
2. Shouldn't you track also Cabal's metadata revisions?
The metadata updates are mostly about dependency versions and bounds, so I usually update that directly in the PKGBUILD instead. Please correct me if I'm wrong here, though.
That's right, you can always manually edit that information on the PKGBUILD.
participants (3)
-
Felix Yan
-
Magnus Therning
-
Nicola Squartini