Re: [arch-general] [arch-dev-public] [aur-general] GHC 7.8.1 packaging decisions for Arch Linux

2014-04-10 Thread Magnus Therning
On Thu, Apr 10, 2014 at 5:21 AM, Daniel Micay danielmi...@gmail.com wrote:
 On 09/04/14 11:12 PM, Allan McRae 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?

 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

Indeed, it's still active.  Not
steaming-full-ahead-lika-a-freight-train active, but we're bringing in
updates and adding new packages at a somewhat leasurely pace :)

The tool that makes it possible is cblrepo - https://github.com/magthe/cblrepo

Beyond that there are a few scripts that makes the chore of keeping
packages up-to-date largely automated.  The experience is that a
single person can keep over 200 packages up-to-date with spending
about 15-30 minutes per week.  The builds of course take longer than
that (sometimes much longer), but they don't require active
monitoring.

/M

-- 
Magnus Therning  OpenPGP: 0xAB4DFBA4
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe   http://therning.org/magnus


Re: [arch-general] [arch-dev-public] [aur-general] GHC 7.8.1 packaging decisions for Arch Linux

2014-04-09 Thread Thomas Dziedzic
On Wed, Apr 9, 2014 at 12:35 AM, Jelle van der Waa je...@vdwaa.nl wrote:

  I would like to keep XMonad/XMobar in [community] it does seem to take up
 a big chunk of the haskell-* packages we have in our repos. But I've never
 ran into real big issues packaging haskell libraries, one minor issue is
 that the developers tend to oversplit packages for example
 haskell-data-default-* . This really makes packaging haskell libraries
 annoying.


I don't want to prevent people from maintaining haskell packages in
supported repos.
I just want to make cabal-install a path with which people don't have to
think twice about.

 I would prefer that we don't package vim plugins or firefox extensions.
 Firefox has it's own extension manager and vim has a lot of solutions which
 work better then pacman


I also share this belief about haskell.
Both pacman and cabal-install have their own pros and cons, but for my
personally, I find that cabal-install has more benefit to me personally for
haskell packages.


  How many haskell developers actually use our packages in the repos/aur
 rather then using caba-install?


I can only speak from personal experience, but I have used cabal-install
exclusively for a couple of years now not just for development but for also
installing tools like xmonad.
My guess is that given the limited supply of packages in our repos, I can
guestimate 0 use it for development but there might be a lot of users that
actually use the haskell tools like xmonad.


Re: [arch-general] [arch-dev-public] [aur-general] GHC 7.8.1 packaging decisions for Arch Linux

2014-04-09 Thread Daniel Micay
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 mag...@therning.orgwrote:

 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



signature.asc
Description: OpenPGP digital signature


Re: [arch-general] [arch-dev-public] [aur-general] GHC 7.8.1 packaging decisions for Arch Linux

2014-04-09 Thread Thomas Dziedzic
On Wed, Apr 9, 2014 at 8:12 PM, Allan McRae al...@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.