Re: [arch-dev-public] [aur-general] GHC 7.8.1 packaging decisions for Arch Linux
On Wed, Apr 9, 2014 at 12:07 AM, Magnus Therning <magnus@therning.org>wrote:
I'm guessing this means cabal-install now is the only package outside of [community] that uses ghc to build. Is that right?
That would be correct.
Is the plan then that any future tools (i.e. non-libraries) implemented in Haskell would go into [community]?
This would also be correct. I believe that most people who use packages in our supported repos don't actually use the haskell libraries themselves, but rather the tools that depend on them. (e.g. xmonad) I am not against keeping these tools around and their dependencies if someone wants to maintain them, but I personally have no interest in maintaining them myself.
<devil advocate> There is nothing that say one HAS to wait for a ghc upgrade in order to provide newer versions of Haskell packages. As you point all that's needed is a rebuild of all the packages that depend on the upgraded one. If that's messy it sounds like you are using bad tools to handle upgrading. Are you really suggesting ArchLinux abandon packaging a whole class of software just because the tools are inadequate? </devils advocate>
I am aware that the way we are packaging haskell packages is non optimal and could be automated away. I already have a tool that automates the rebuild of [extra] packages, but since I don't/want to maintain any packages that aren't dependencies of cabal-install, I haven't looked into automating those builds. I don't want to focus solely on this point though because I just felt like I should make people aware of this problem. This isn't the only reason why I want to move away from haskell packages in pacman. It should be noted that cabal-install isn't a package manager in the
true sense[1]. I'm not sure this is an argument against making the change you propose, but it's worth noting.
I agree. Cabal does lack even basic features that other people would expect from a package manager. For example, upgrades, removal. Although there are ways to have the same effect as upgrading since you can have multiple versions of the same package installed, you could just install the same package after a cabal update. That's why I suggested writing up a tip sheet on basic cabal usage for people who aren't as used to cabal as others.
There are quite a few other language/frameworks that have language-specific build/package systems, Python, Ruby, Perl, node.js... Are Python developers on Arch pointed towards using pip to install Python libs?
I think that the languages you mentioned could be split up into 2 categories. Python and Perl have a large number of interested developers and trusted users maintaining those packages. Python has over 700 packages, and Perl has over 500 packages and so, there is a lot of interest in those languages. On the other hand, you have Haskell, Ruby, and Node.Js where they have a smaller following. Haskell has about 90 packages (including i686/x86_64), Ruby has about 60, and Node.Js has approximately none. The popular languages have a critical mass which I believe lets people get away with using the pacman package manager. So for languages like python and perl, it might make sense to use pacman. But for languages like haskell, ruby, and node.js I believe using the system package manager leaves a lot to be desired.
How do you envision this actually working?
I would like to officially announce that there are 2 paths of maintaining haskell packages on your system. One would be using cabal-install and I would encourage users to try using it. The other would be to use whatever is in the supported repositories. I would also like to officially announce that one or the other is supported, but they should be mutually exclusive.
The set of packages in [extra]/[community] is rather small today, in the order of 3 dozen, so does this mean that users are already turning to the Arch devs when they are having problems compiling Haskell packages?
No. I believe that most users actually know what the correct path is. I just want to make it officially announced rather than having any potential confusion on which path to take and which paths are supported.
On 10/04/14 12:58, Thomas Dziedzic wrote:
On Wed, Apr 9, 2014 at 12:07 AM, Magnus Therning <magnus@therning.org>wrote:
I'm guessing this means cabal-install now is the only package outside of [community] that uses ghc to build. Is that right?
That would be correct.
Is the plan then that any future tools (i.e. non-libraries) implemented in Haskell would go into [community]?
This would also be correct. I believe that most people who use packages in our supported repos don't actually use the haskell libraries themselves, but rather the tools that depend on them. (e.g. xmonad) I am not against keeping these tools around and their dependencies if someone wants to maintain them, but I personally have no interest in maintaining them myself.
I am fine with this decision. Although I think it better to use a system package manager if at all possible, I do recognise that this takes man power that we do not have for haskell. People still have the option of using the AUR over cabal-install if they want to use the package manager (or system wide installs - is cabal-install a per user thing?) <aside> In my ideal situation, we would have a team of people for each of the "major" programming languages who would determine packaging policy and provide packages for many of the libraries for that language. Sort of like how we have multiple people who deal with KDE and GNOME updates. With a team based setup, it would be easier to have more junior people brought on to help. </aside> Now that aside is finished, what is the deal with that arch-haskell group? Is it still going? Would they want to provide packages officially instead? I know that this does not solve the issue of ghc embedding hashes and thus requiring rebuilds for even minor updates... Allan
On 09/04/14 11:12 PM, Allan McRae wrote:
On 10/04/14 12:58, Thomas Dziedzic wrote:
On Wed, Apr 9, 2014 at 12:07 AM, Magnus Therning <magnus@therning.org>wrote:
I'm guessing this means cabal-install now is the only package outside of [community] that uses ghc to build. Is that right?
That would be correct.
Is the plan then that any future tools (i.e. non-libraries) implemented in Haskell would go into [community]?
This would also be correct. I believe that most people who use packages in our supported repos don't actually use the haskell libraries themselves, but rather the tools that depend on them. (e.g. xmonad) I am not against keeping these tools around and their dependencies if someone wants to maintain them, but I personally have no interest in maintaining them myself.
I am fine with this decision. Although I think it better to use a system package manager if at all possible, I do recognise that this takes man power that we do not have for haskell. People still have the option of using the AUR over cabal-install if they want to use the package manager (or system wide installs - is cabal-install a per user thing?)
<aside> In my ideal situation, we would have a team of people for each of the "major" programming languages who would determine packaging policy and provide packages for many of the libraries for that language. Sort of like how we have multiple people who deal with KDE and GNOME updates. With a team based setup, it would be easier to have more junior people brought on to help. </aside>
Now that aside is finished, what is the deal with that arch-haskell group? Is it still going? Would they want to provide packages officially instead?
It's definitely still active. They seem to have all the necessary automation worked out. AFAICT they do an automated conversion from the cabal files and maintain a set of patches for adding external dependencies, etc. https://github.com/archhaskell
On Wed, Apr 9, 2014 at 8:12 PM, Allan McRae <allan@archlinux.org> wrote:
Now that aside is finished, what is the deal with that arch-haskell group? Is it still going? Would they want to provide packages officially instead?
I wouldn't actually be opposed to this idea. A lot of effort is duplicated with regards to Archlinux's official haskell packages and Arch-Haskell's packages. We could try to work out something between the existing haskell package maintainers and arch-haskell maintainers. It might lead to a possibly better overall haskell experience on archlinux. Arch-haskell could maintain official haskell packages using pacman. I (and anyone interested) could support haskell package installation using the cabal-install route.
participants (3)
-
Allan McRae
-
Daniel Micay
-
Thomas Dziedzic