On 24 August 2010 16:15, David Virebayre wrote:

2010/8/24 Ivan Lazar Miljenovic :

...

What do you mean by "metapackages"?

Metapackage are packages of packages, they don't provide something by themselves, but they have a dependency list so that a set of package can be installed together.

For example, on ubuntu, installing "build-essentials" will pull gcc, make, autoconf, etc from the repositories.

Another example would be the haskell platform, on debian it's a metapackage that depends on all the individual packages of libraries and tools that belong to the platform.

That's what I thought; I don't see how this makes dealing with Haskell packages any easier (unless you want to specifically install the Haskell Platform rather than the individual libraries/tools you want/need, which is my preference). -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

On 24 August 2010 17:45, Mathew de Detrich wrote:

On Tue, Aug 24, 2010 at 5:55 AM, Ivan Lazar Miljenovic wrote:

...

On 24 August 2010 15:50, Mathew de Detrich 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@gmail.com IvanMiljenovic.wordpress.com

Hi, Am Dienstag, den 24.08.2010, 09:30 +0100 schrieb Magnus Therning:

On Tue, Aug 24, 2010 at 06:50, Mathew de Detrich wrote:

...

- 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)

This is arguably an error in the Arch packages. The dependencies aren't quite as strict as they really should be. I've taken the approach of never letting pacman update any haskell-* package. Instead I do a small song-and-dance where I first remove the packages in question, and any package that depends on them, then I re-install what I just removed.

In Debian, this cannot happen any more, as libraries are tied to the packages of their dependencies via the ABI hash used by ghc. (If I am correctly understanding the symptoms). So using apt-get upgrade will never break any Debian-installed packages. It can however happen that your per-user cabal-install’ed packages break, but this can be easily fixed by using cabal install again. OTOH, you cannot expect Debian to always and immediately install the latest Cabal versions – there are possibly good reasons for not upgrading. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata

On 24 August 2010 21:18, Joachim Breitner wrote:

Hi,

Am Dienstag, den 24.08.2010, 09:30 +0100 schrieb Magnus Therning:

...

On Tue, Aug 24, 2010 at 06:50, Mathew de Detrich wrote:

...

- 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)

This is arguably an error in the Arch packages.  The dependencies aren't quite as strict as they really should be.  I've taken the approach of never letting pacman update any haskell-* package.  Instead I do a small song-and-dance where I first remove the packages in question, and any package that depends on them, then I re-install what I just removed.

In Debian, this cannot happen any more, as libraries are tied to the packages of their dependencies via the ABI hash used by ghc. (If I am correctly understanding the symptoms). So using apt-get upgrade will never break any Debian-installed packages.

Interesting; I've been discussing with Ciaran McCreesh on a possibility of getting something like that into Paludis for use with Exherbo (a few non-Haskell related things are starting to annoy me with the petty politics, etc. of Gentoo and Exherbo has some really nice ideas). How exactly do you do this? Register the ABI hash upon installation and check if it ever changes? Or is this all done when you build the package since Debian uses binary packages?

OTOH, you cannot expect Debian to always and immediately install the latest Cabal versions – there are possibly good reasons for not upgrading.

Yes, least of which is someone spending the time to notice that a package is out of date and bothering to update it + test that update (including any packages that depend upon it). -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com