[Fedora-haskell-list] Package guideline feedback

[Bryan O'Sullivan]

Brief comments on http://fedoraproject.org/wiki/PackagingDrafts/Haskell

> There are three types of packages: Library only, Library and Binary, and Binary only. The program cabal-rpm can generate a SPEC file suited to all three cases. The following templates are the output from cabal-rpm with a few minor changes.

Actually, there are really only two: library and binary.  Mixing
libraries and binaries is deprecated, and we shouldn't support it.

> Naming
> 
> I need some input here. I am also not sure how we want to name our packages in CVS.

For libraries, ghc-foo and hugs98-foo and nhc-foo and so on.

For binaries, the plain name, as for other Fedora packages.

> Questions
> 
>     * Where should libraries go? 
> 
> Libraries are stored at /usr/lib/ghc which is a symlink to the current version.

It's actually a regular directory with a subdirectory per version.

>     * Some libraries (like X11) that are included with GHC are not the newest version. Some packages like xmonad need a newer version. Do we break apart the GHC package into multiple libraries that other packages can also update from other sources? 
> 
> I would love to do this.

I can't tell who's making these comments.  If you're commenting directly
in the wiki, could you include your initials or something, so we can
tell who's saying what?

I'm not thrilled with the idea of splitting up ghc and the extralibs,
because it's a pain to have to install a dozen packages after ghc itself
on systems that do the split, like Debian.

If we can come up with some scheme that does the split, but gets the
whole lot installed in one go, then fine.

It's also perfectly reasonable, as far as GHC is concerned, to have
multiple versions of a package installed at once.

>     * How do we handle Haddock data? Do we mandate haddock packages go in -doc? -haddock? should we enforce special build time requirements to make sure all haddock packages hyperlink to one another? (I'm new to this, how do we make that work) 
> 
> More research is needed here. This will not make it into Fedora 9 most likely.

Haddock should pick up links across packages properly by default.

>     * Using cabal-rpm, -debuginfo packages come up empty. Is something supposed to go in them? 
> 
> This is show stopping for the review process. I need someone's input on why this is happening.

debuginfo packages shouldn't even be built.  GHC doesn't emit DWARF
debug data.

> -devel sub-package
> 
> Do we need them?

No.

> Binaries are packaged by their simple name. xmonad would remain xmonad, as would xmobar. This does not apply to the libraries that are included in the cabal package. A spec file for xmonad would generate two rpms, both of which are required for runtime, xmonad and ghc-xmonad. xmonad would require ghc-xmonad, but not vica versa. ghc-xmonad would contain a line in the description explaining that these are the libraries necessary for xmonad to run.
> 
> Rationale: binary packages tend to become popular on their name alone, and sometimes people may be looking for a program not caring that it is written in Haskell or Brainfuck. If a package containing a binary named xmobar is named xmobar, as upstream calles the entire thing xmobar, xmobar will be the easiest way for the user to find the package.

More to the point, a built binary doesn't depend on the compiler it was
built with, so there's no reason to include the compiler name.

> Good Haskell libraries should be as generic and algorithmic as possible. It's possible that someone may want to use an algorithm provided by a library such that when the upstream provider releases the project as a cabal package generating both binaries and libraries, we would want to treat the library component the same as any other Haskell library for the sake of that user.

I cannot understand these sentences.

> Documentation
> 
> I have to do a bit of research on making Haddock interact correctly with all the other included packages. The biggest challenge is making sure all packages are hyperlinked to each other correctly. This may require an expensive post package install relinking phase for every Haskell library. I would like to avoid this, so it will involve some research.

It ought to simply work.

	<b