[Haskell-cafe] Hackage on Linux

[Ivan Lazar Miljenovic]

On 24 August 2010 17:45, Mathew de Detrich <deteego at gmail.com> wrote:
>
> On Tue, Aug 24, 2010 at 5:55 AM, Ivan Lazar Miljenovic
> <ivan.miljenovic at gmail.com> wrote:
>>
>> On 24 August 2010 15:50, Mathew de Detrich <deteego at gmail.com> wrote:
>> >
>> > - packages on archlinux don't auto update when cabal does. This becomes
>> > really annoying when package X gets updated on cabal but not on arch and
>> > causes conflicts with other packages
>>
>> Huh?  Are you referring to doing a "cabal update"?  If so, how is this
>> causing conflicts?  Are you mixing and matching distro packages with
>> packages installed by hand?
>
> No I am referring to doing an update through packer -Syu or clyde -Syu (the
> archlinux wrappers for updating packages uploaded through aur). Right now I
> just use standard cabal-install, because I got sick of this happening (and
> haven't had any issues)

I still don't get how this is a problem, unless package foo depends on
package bar, package bar is updated but not package foo.

>> I thought Don kept the external Haskell repository up to date with the
>> packages on Hackage...
>
> They are not auto updated, they are updated whenever a maintainer updates
> them. You can check here for more info
> http://www.galois.com/~dons/arch-haskell-status.html
> If the aur packages were auto-updated (assuming they could be built)
> whenever a package was updated on hackage, that would be a different story

And I would argue that this is a good thing: I'm rather leery of
auto-generated packages being used "in the wild", probably due to the
amount of fiddling needed to get some ebuilds for Haskell packages
working (admittedly, this fiddling is partially due to limitations on
what ebuild dependencies can contain, partially due to some quirks
that our hackport tool still generates but mainly because we tend to
sometimes tweak how the package is built with USE flags,
loosening/tightening deps, etc.).  Also, I'm not sure of any
auto-generated package being able to cope with non-Haskell
dependencies properly (due to not being able to match up the specified
C library names to the proper package names, or due to "implicit"
dependencies not actually able to be specified as such in the .cabal
file).

>> > - in some situations doing a general update with arch (through clyde or
>> > packer)  breaks ghc (last time it happened packer tried to
>> > uninstall/update
>> > arch packages which failed because those packages had dependencies. The
>> > files got removed but since unregister failed ghc thought they still
>> > existed)
>>
>> Is this the problem with bad packages or the package manager playing up?
>
> What happened at the time, was updating haskell-gtk (or gtk on cabal) caused
> packer (the package manager for AUR) to uninstall/update the haskell-gtk
> packages (can't remember which one). So when the haskell-gtk package (and
> its dependancies) where installed, it obviously invoke ghc-pkg unregister
> (which is what you are meant to do when you uninstall a package). However
> other packages dependant on those haskell-gtk packages, which meant that
> ghc-unregister failed (obviously) however the library files were still
> removed, which for obvious reasons broke ghc. This has happened many times
> before though (around 3 times for me)

At a guess, is this because of a fault in the pre-Cabalised gtk2hs?
Since it didn't use Cabal, registering and unregistering it was a
little quirky if memory serves...

> Another much more common issue is when you are trying to install some
> package (through AUR) and it has dependencies on some packages (also through
> AUR) however that package happens to be outdated. So then you have to
> manually build the package, and if it depends on some other packages things
> get even worse (kind of like dependency hell, haskell version). With just
> using cabal, you can do cabal install or cabal update. Again this is an
> issue that goes to my previous point, where packages on AUR (that are not
> just the base ones) aren't fully updated

Does it really matter to much to you as an end user if a package is
outdated?  I mean, yes, I like to keep the Haskell packages I use
either directly or indirectly updated in terms of ebuilds for Gentoo
as much as possible, but does it really hurt if it takes a month or so
for the repository maintainer to update said packages (assuming
there's not some large bug with the older version)?

Speaking of such, you could always help out by a) asking Don or
someone else that said package is out of date, and b) actually helping
to create Haskell packages.

> Note that these problems aren't just foreign to Haskell, other languages has
> it as well (to some degree). I have had similar issues with building
> outdated C/C++ programs, its just that due to the way people program/build
> in C/C++, they use a few huge libraries (as opposed to a large collection of
> smaller libraries) so when problems do occur you don't have
> many dependencies that you have to deal with. In Haskell, its not uncommon
> to have libraries/programs with >15 dependencies. I actually prefer the
> Haskell way of doing things, because its much more modularized, it just
> means that if you have issues with dependencies in libraries they are
> amplified. Ruby is another language that favors using many libraries,
> however everyone that uses Ruby just uses gems (kind of equivalent of
> cabal-install) and Ruby being a primarily interpreted/scripted language
> makes things less painful then one that is primarily compiled (such as
> Haskell)

If memory serves, Arch also only has one version of each package; does
this ever lead to problems when package Foo depends on Bar-x, and
package Baz depends on Bar-y (where x /= y)?  If so, maybe this is one
reason why packages aren't updated instantly...

>> > Apart from base/required packages, unless your linux distro has proper
>> > metapackages its in my opinion just better off using cabal install (and
>> > only
>> > use arch packages for binaries)
>>
>> What do you mean by "metapackages"?
>>
> Metapackages would mean that when you do an update/install through your
> distro (for my archlinux system it would be packer -S haskell-gtk for
> example) then it wouldn't actually install (or sync) a package containing
> files. Instead what would happen is that invoking packer -S haskell-gtk
> would just invoke a cabal-install (with a pre-configured .config file I am
> assuming). More importantly, if you do something like ghc-unregister on a
> package and it fails, the package wouldn't actually successfully uninstall
> (and screw up ghc) as it did in my example above

Oh, so you want to be able to have "virtual" packages that
auto-generate the package you want if it isn't already available?
IMHO, that's a really bad idea and fraught with possible problems (see
my comments on this above).  And in the gtk case, now that it's
cabalised this shouldn't be as much of a problem.

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