Hi Gregory, Thanks for the reply. Gregory Collins wrote:

Sean Leather writes:

...

4. The current link for the Mac image points to

http://hackage.haskell.org/platform/2010.1.0.0/haskell-platform-2010.1.0.1-i...

...

. Note the inconsistency between the version in the directory and file names.

You can think of that one as the second edition of the 2010.1 beta version. Agree that the directories should match.

This is, of course, relatively minor. One alternative is to change the directory name to exclude the lowest version(s), e.g 2010.1/haskell-platform-2010.1.0.1-i386.dmg, so that when new intermediate versions are uploaded, the directory name still makes sense and doesn't need to change. Too bad the installer

still doesn't work -- I'm working on it everyone, but the Mac installer system is incredibly crufty and broken, and Snow Leopard broke a lot of stuff for me.

Is it possible to build the installer on a Leopard system/virtual machine such that it will install on a Snow Leopard system?

5. The directions on http://hackage.haskell.org/platform/mac.html say:

...

After downloading: * Open the .dmg file * Follow the install instructions

I see no "install instructions" in the .dmg file. I only see the

following files:

...

* GHC-6.12.1-i386.pkg * Haskell Platform 2010.1.0.1.pkg * Uninstall GHC

When you mount the .dmg file a Finder window should pop up with the install instructions in a background image. Let me guess: this isn't working in Leopard? I should put a readme in there.

Yes, I'm using Leopard. A README file should do the trick.

7. Why can't I have a single .pkg file?

Short answer: I can't figure out how, and not for lack of trying, either. What I do is take the binary installer that the GHC guys build as a starting point. Despite many hours of reverse-engineering I cannot for the life of me figure out how to extract the GHC installer package from the binary "metapackage".

I'm completely ignorant of how the installer packages work, but is it possible to have one package refer to another? Thus, one installer could initiate another. Then, at least there is only one click needed for the whole thing. My experience has been that if you unxar the metapackage and try to copy

the included package file into a new metapackage, the mac installer tools barf. Long-term, I'm planning on just building GHC from source so I can package a one-click installer, but I don't have infinite time for this project and doing psychic battle with the evil warlocks who cooked up the Mac installer is a challenge.

I see you have the source at http://github.com/gregorycollins/haskell-platform-osx-installer . I can try to look at it at some point. If anyone has expertise in this area and a willingness to help, please

contact me off-list.

...

Why do I have an "Uninstall GHC" and not an "Uninstall Haskell Platform"?

The platform installer is supposed to erase previous platform editions before it installs itself.

That's good. Is it possible to include an uninstaller as well? Regards, Sean

...

The platform installer is supposed to erase previous platform editions before it installs itself.

I would consider that a serious bug. The Haskell Platform is not like a standard user application, where it would be reasonable to have only one version installed at a time. If you are a software developer, it is frequently essential to have several different versions of the development environment (compiler + libraries) installed simultaneously, so that you can adequately support users who have different versions of your own software. Regards, Malcolm

...

...

...

The platform installer is supposed to erase previous platform editions before it installs itself.

I would consider that a serious bug.

"Lacking a feature I would consider essential" /= "a bug" in my opinion, especially when the desirability of the feature is in question.

It is not merely that a feature is lacking. Removing software from my machine without my knowledge or permission is just wrong. (I was bitten by this once before, with a ghc installer for Mac. It removed the previous working ghc, without telling me. Then I discovered that a library I needed could not be compiled by the new version of ghc. The old ghc installer then refused to delete the new ghc and revert to the old one, because it could not imagine why anyone would want to "downgrade".) Regards, Malcolm

On Wed, Apr 7, 2010 at 2:57 PM, Malcolm Wallace < malcolm.wallace@cs.york.ac.uk> wrote:

The platform installer is supposed to erase previous platform

...

...

...

...

editions before it installs itself.

I would consider that a serious bug.

"Lacking a feature I would consider essential" /= "a bug" in my opinion, especially when the desirability of the feature is in question.

It is not merely that a feature is lacking. Removing software from my machine without my knowledge or permission is just wrong. (I was bitten by this once before, with a ghc installer for Mac. It removed the previous working ghc, without telling me. Then I discovered that a library I needed could not be compiled by the new version of ghc. The old ghc installer then refused to delete the new ghc and revert to the old one, because it could not imagine why anyone would want to "downgrade".)

If I understand correctly, the issue at hand is that the uninstaller step is removing previous libraries and ghc? If so, then I completely agree with Malcolm here. Having the installer only allow one version of ghc means I'll keep using the tarball provided by GHC HQ instead of the nice shiny installer for the HP. I need to be able to test things on multiple GHC versions for the foreseeable future. I have a workaround, but I implore you to please kindly reconsider your stance here. Jason

greg:

Jason Dagit writes:

...

If I understand correctly, the issue at hand is that the uninstaller step is removing previous libraries and ghc?

Not GHC; the HP installer removes old copies of the platform libraries. That's likely to break your old GHC setup though. What should it do instead?

Can we install these in parallel somehow? A la lib/ghc-6.8.2 lib/ghc-6.6.1 lib/ghc-6.10.2 lib/ghc-6.12.1 ?

Am Mittwoch 07 April 2010 23:43:05 schrieb Ivan Lazar Miljenovic:

Malcolm Wallace writes:

...

The Haskell Platform is not like a standard user application, where it would be reasonable to have only one version installed at a time.

As far as I know, most Linux distributions only let you install one version of GHC at a time;

I currently have 6.10.1, 6.10.3 and 6.12.1 installed (openSuSe 11.1), no problem. On my previous computer (SuSE 8.2), I had every release from 6.2.2 to 6.8.2, no problem either.

we do this with Gentoo because despite there being some distribution-specific architecture in place to be able to switch between compilers (used for GCC, Ruby, Python, etc.) we haven't resolved how to deal with dependency problems when a library was built with one version of GHC and then you try to build something that depends upon it with another version of GHC (since the package manager _knows_ that the dependency is installed, yet GHC is vehement that it knows nothing about it).

Ah, but one shouldn't use a package manager for Haskell packages. Cabal is far superior to all of them 8-)

Am Donnerstag 08 April 2010 00:09:34 schrieb Ivan Lazar Miljenovic:

Daniel Fischer writes:

...

I currently have 6.10.1, 6.10.3 and 6.12.1 installed (openSuSe 11.1), no problem. On my previous computer (SuSE 8.2), I had every release from 6.2.2 to 6.8.2, no problem either.

Using system packages?

Of course not, I'm a source freak (except the 6.10.1, one has to get started somehow).

...

Ah, but one shouldn't use a package manager for Haskell packages. Cabal is far superior to all of them 8-)

Except for the fact that you can't uninstall,

Well, I can uninstall manually if I really want to, but disk space isn't that scarce yet.

check for non-Haskell-library dependencies,

True, a distro package manager could do that. However, so far I've found the ease of managing Haskell packages via cabal- install worth much more than taking care of the occasional non-Haskell dependency.

etc. ...

Such as?

Am Donnerstag 08 April 2010 01:47:19 schrieb Ivan Miljenovic:

On 8 April 2010 08:25, Daniel Fischer wrote:

...

Am Donnerstag 08 April 2010 00:09:34 schrieb Ivan Lazar Miljenovic:

...

etc. ...

Such as?

To avoid stating these all over again: http://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is- not-a-package-manager/ (specifically the section titled "Why you should use your distribution’s package management system").

Fair enough, Cabal/Hackage/cabal-install certainly isn't a package manager (good that I never claimed it was :), I just use it to manage my Haskell source packages; no, I won't stop doing that, I'm not going to switch distros, I like SuSE, I didn't like Ubuntu or sidux, I might give Gentoo a try when I buy my next computer, though). However, I wanted to know what the etc stood for, with taking care of dependencies and uninstalling already mentioned. Upgrading, yes, but what else?

Daniel Fischer writes:

However, I wanted to know what the etc stood for, with taking care of dependencies and uninstalling already mentioned. Upgrading, yes, but what else?

Keeping the system consistent with other systems? If I use the system packages, I can have a higher confidence that what works for me will also work for users of the same distro. And converse, so there'll be more eyeballs per problem. Reducing the load on system admins? Although I might know the pros and cons of upgrading to GHC 6.12.y from .x, my IT department are not likely to. And they have to support a dozen different languages for several dozen users. They are also more likely to trust things they get from apt or yum repos, than tarballs off some random web site. Centrally managed bug reporting system? Not that Launchpad is awsomely responsive, but at least there's *something*. Support, in the sense that somebody is actually responsible for the package? (Unlike Hackage, where some packages have a closed-for-nonsubscribers mailing list as 'maintainer'.) (Probably 'etc.', but I can't think of more points at the moment.) -k -- If I haven't seen further, it is by standing in the footprints of giants

On Apr 8, 2010, at 02:47 , Ivan Miljenovic wrote:

On 8 April 2010 16:29, Ketil Malde wrote:

...

Support, in the sense that somebody is actually responsible for the package? (Unlike Hackage, where some packages have a closed-for-nonsubscribers mailing list as 'maintainer'.)

Which packages are these? I don't recall seeing any with this kind of "maintainer" address...

-cafe is closed for posting by nonmembers, as a spam limiter. I'm pretty sure that's what he meant. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Sean Leather writes:

Personally, I prefer to separate the name of the language from the name of the development tools, because I think that causes unnecessary confusion. End-users do not need to care about Haskell, unlike Java since they need the JRE, so potential developers and students are the audience. This group needs the Haskell Platform for developing with Haskell, and having the tools referred to as "Haskell Platform" is clear enough (imho) without having to call the tools "Haskell."

I think the partial confusion here is that most "newer" languages have the same name as their defacto implementation (Python [though the implementation is technically CPython], Perl, Ruby, etc.). Whilst Haskell has other implementations apart from GHC, none of the others are as featureful, etc. So pretty much if you want "Haskell", then you want GHC. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com