[Haskell-cafe] Hackage on Linux

[Ivan Lazar Miljenovic]

On 25 August 2010 14:36, Mathew de Detrich <deteego at gmail.com> wrote:
>
>
> On Wed, Aug 25, 2010 at 1:59 PM, Ivan Lazar Miljenovic
> <ivan.miljenovic at gmail.com> wrote:
>> Consider these scenarios:
>>
>> 1) You upgrade package foo; this breaks a large number of other
>> packages.  How do you deal with it?
>
> Thats what happened when I was using archlinux for libraries, nothing has
> broken with cabal. And if cabal somehow does break when installing
> libraries, I know where all the libraries are (in one folder) so its easy to
> fix (just delete folder, unregister packages) instead of having to do it
> through a package manager

Ummm, why should you need to unregister packages, etc.?

I'm talking about a situation where bar depends on foo-x.y.*, and you
upgrade foo from x.y.1 to x.y.2 (and "ghc-pkg check" will then
complain about bar being broken).

>> 2) You upgrade GHC.  You now have to manually re-build all packages
>> that you had built with the previous version of GHC.
>
> Base libraries that game with GHC I left alone (as I mentioned earlier).
> Packages such as parallel and array are installed by GHC and left alone

But all the other libraries that you built with cabal-install?

>> 3) You want to uninstall some Haskell packages.
>
> Blame cabal for not having cabal uninstall =D. Also you can unregister the
> package through GHC (to check if it doesn't depend on anything) and delete
> the library folder (thats what uninstalling the aur packages does anyways,
> just instead of deleting the library folders the files get removed through
> the package manager)

Well, yes, but that's my point: the package manager handles that.

>> 4) You built a package with non-standard build options; cabal-install
>> keeps wanting to rebuild it with the defaults.
>
> Havne't had this issue yet, can you be more specific (gtk for example
> installed fine through cabal-install, I believe thats something thats
> regarded as a non standard install). Remember that there is nothing stopping
> me from installing archlinux aur packages if for whatever reason
> cabal-install doesn't work, and thats highly unlikely because AUR packages
> are built by using runhaskell configure/build etc in the first place

e.g. you want to build gtk with --flag=-have-gio ; next time you want
to build anything with cabal-install that uses gtk, cabal-install will
want to re-build gtk and reset that option to --flag=have-gio (the
default).

>> 5) You don't want to wait for a package maintainer to loosen the
>> dependencies of a package you know works with a newer version of a
>> dependency.
>
> This is also an issue in AUR, so AUR ain't any better

Well, if you help out maintaining AUR you can then go and do said
loosening yourself.

>> 6) You want to install package bar; it fails to build due to some
>> missing C library/build tool/etc.  You have to dig around and work out
>> which system package contains that C library/Haskell package contains
>> that build tool/etc. and install that first.
>
> I installed two packages that depend on C libraries (wx and gtk) without any
> issues (through cabal-install). cabal-install works with C libraries the
> same way it does when you do runhaskell configure/build

*sigh* my point is, you have to know to install the C libraries first.
 cabal-install can bitch that a C library isn't installed, but you
then have to work out what the proper package name is and install it.

Some more concrete examples:

* At some stage the HEAD version of darcs had a dependency on the
"icuuc" library; it took me a while to work out that the corresponding
Gentoo package for this library was dev-libs/icu

* I wrote and maintain SourceGraph; someone that used cabal-install to
install it on a (I think) Ubuntu box emailed me to state that it came
up with a lot of broken handle error messages rather than generating
the report as required (I thought I had caught those exceptions; I'm
still trying to work out where to catch them to have a better
message).  The reason?  He didn't have Graphviz (as in
www.graphviz.org) installed, which my graphviz library (that
SourceGraph uses) uses to actually render the DotGraph values into
images.  This isn't caught at build-time as it's a run-time dependency
(i.e. it isn't using it as a library but as a command-line tool to
run).  A proper distro package should have that dependency in there
(e.g. http://code.haskell.org/gentoo/gentoo-haskell/dev-haskell/graphviz/graphviz-2999.10.0.1.ebuild
).

>> Now, some future version of cabal-install may in fact solve the first
>> four problems by automating them and keeping track of installed
>> packages itself rather than relying on ghc-pkg.  It will _never_ be
>> able to solve the latter two (OK, it might be that someone adds
>> functionality to add "tweaks" to a package at configure/build/etc.
>> time).
>
> I never had these problems, if there is a problem with cabal-install it will
> be a problem with Archlinux AUR packages, because cabal-install does
> configure/build in its process anyways. The only exception is binaries, and
> as stated before I do install them through Archlinux AUR

Then you mustn't be doing much with Haskell, and despite your previous
complaints you mustn't upgrade many low-level Haskell libraries often.
 I get broken packages all the time; that's why I gave up and wrote
haskell-updater for Gentoo to automate re-building of broken packages
(essentially it gets the output of "ghc-pkg check", matches the listed
packages with the corresponding distro packages and then tells the
package manager to rebuild them).

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
IvanMiljenovic.wordpress.com