Bug 982204

I think it might be better to call the package "Elm".

At least cabal-rpm currently assumes that name = pkg_name
for BinLib packages like this and it is also recommended
in the Haskell Guidelines.  (Failing that probably need to replace
%{name} with %{pkg_name} in various places in the spec file.)

Some more comments:

- Perhaps the Summary could be more descriptive.
  How about: "Functional reactive web programming lanaguage"?

- Latest upstream version is now 0.9.0.2 though it needs union-find.

- You will probably have to ExcludeArch armv7hl for now since pandoc
  refuses to build there currently with ghc-7.6.3 and llvm-3.3 (f20).
  Hopefully that should improve in F21 when we move to ghc-7.8.

(In reply to Jens Petersen from comment #1)
> I think it might be better to call the package "Elm".
> 
> At least cabal-rpm currently assumes that name = pkg_name
> for BinLib packages like this and it is also recommended
> in the Haskell Guidelines.  (Failing that probably need to replace
> %{name} with %{pkg_name} in various places in the spec file.)

Well it seems to build and install okay here but I still
recommend using "Elm" since it is more consistent and
I think some of the haskell-sig script might get confused
if the package and hackage names are different.

(In reply to Jens Petersen from comment #2)

> Well it seems to build and install okay here but I still
> recommend using "Elm" 

Just a remark: I guess you are aware, there once was a then-very-popular email client called "elm" [1]. Though I am not aware about any current Linux distro is shipping it, I'd expect finding a package named "elm" would cause some confusion *nix old-timers ;)

[1] http://en.wikipedia.org/wiki/Elm_%28e-mail_client%29

(In reply to Ralf Corsepius from comment #3)
> Just a remark: I guess you are aware, there once was a then-very-popular
> email client called "elm" [1]. Though I am not aware about any current Linux
> distro is shipping it, I'd expect finding a package named "elm" would cause
> some confusion *nix old-timers ;)

Right - it had crossed my mind.
I did a little digging and as far as I can tell
the last release that shipped with elm was RHL 7.3 (2002).
(I don't see it in Fedora Extras either.)
So I hope this is not a big concern still now.
But it might be an additional argument for
calling this package "Elm" instead of "elm". :)

(If it is really is a concern perhaps we could call
it elm-lang in line with the upstream website
but this will only makes maintenance life harder.)

The latest version of Elm requires two new dependencies: uniplate (which is already packaged) and union-find which is not. I will package up union-find and try to finish up getting Elm into Fedora.

Actually, elm isnt as easy and isnt as good.
It kind of sucks because its hard, useless, complicated, none helpful comments and so on and so forth. I wont use that anymore.

(In reply to Leon Neo from comment #6)
> Actually, elm isnt as easy and isnt as good.

compared to what?

There is also helm, though I haven't tried it.

Latest version is now 0.11 with some news features:
http://elm-lang.org/blog/announce/0.11.elm

Even better no additional deps afaics.

Latest now 0.12 - I /think/ still no more deps.

Actually Elm > 0.10.0.2 requires binary >= 0.6.4.0, ie ghc-7.8!

So targeting 0.10.0.2 currently seems best
at least until ghc-7.8 is in rawhide.

I wonder if it is better to use the tarball releases from github for now
which includes the standard library.

Otherwise the following spec file seems to build okay
with fedora macros/cabal-rpm without libraries/ from hackage:

http://petersen.fedorapeople.org/reviews/Elm.spec

but probably better to include libraries/?

I opened https://github.com/elm-lang/Elm/issues/580
to request including the libs in the hackage releases.

(In reply to Jens Petersen from comment #11)
> I wonder if it is better to use the tarball releases from github for now
> which includes the standard library.

Seems this is not necessary actually.
The Elm package already includes the compiled libraries, see:

> https://github.com/elm-lang/Elm/issues/580

Though I dunno if it would still not be better to do so strictly
- more Fedora-esque perhaps?  (building from source afap)

Deprecated in Hackage in favor of elm-compiler