[Fedora-haskell-list] Package guideline feedback

[Yaakov Nemoy]

On Feb 13, 2008 3:26 AM, Bryan O'Sullivan <bos at serpentine.com> wrote:
> 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.

Ok, I understood this bit differently.  xmonad uses a hybrid package
however though, publishing parts of it as a binary and parts as a
library.  The cabal file should yield an rpm that builds two packages
in this case, unless the xmonad guys plan on changing things.
cabal-rpm already supports it, and as you probably know, my patches
fix it up a bit.

You say this is deprecated.  My original goal is to get xmonad in
fedora, so as long as xmonad keeps doing this, i'm going to try to
support it as best as I can.

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

Thanks for your input!

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

Ok, my error here.

>
> >     * 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?

These are my comments.  Sorry for the omission.

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

I'm not sure which part you don't like.  If GHC comes with libs foo
and bar, I would suggest that the package ghc112 depends on foo >=1
and bar >=1.1.  This way, 'yum install ghc' would pull in those two
packages automatically.  When a new version of foo comes out, we can
install ghc-foo-1.1-1, and have it override the version that comes
with GHC upstream.

I am presuming we only want to support one version of a library at a
time, which I am all for.  If this doesn't work, then we'll have to do
something else.

While i'm on the topic of the ghc (and possibly other haskell
compilers) package, I want to suggest a change as well.  Currently
cabal-rpm maintains a list of libraries and versions that are provided
with a ghc compiler.  This list needs to be maintained by hand.  When
generating an rpm spec file from a cabal file, it removes the
dependency that resulting package has on those libraries, because it
is known that it is included in the GHC main package.  What if the GHC
package were to 'provide' libraries such as 'ghc-foo' and 'ghc-bar'
when it has them, so that we don't need this long list in cabal-rpm?
Then, when yum tries to resolved those dependencies, ghc${ver} can
provide them automatically.

This gives us the added advantage in the edge case where a ghc package
has been compiled without the extra libraries.  Since it won't
'provide' those libraries, the administrator will know he needs a
separate set of packages for those standard libraries.

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

Other than yum?

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

Do we want to support this?

> >     * 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.

I wasn't sure how well it worked.  It's something I want to guarantee
to work though, so I think we'll probably have bugs here, as all good
software does.

> >     * 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.

Ok, best we instruct cabal-rpm not to generate spec files that build
debug-info packages at all, and specify this is the guidelines.

Thanks for the answer.

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

Also good to know.

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

Sure, I was having fun being wordy that night.

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

This goes back to the possibility of a cabal file that ultimately
yields both binary and library packages.  The philosophy is to enable
package developers to create packages that put as much code in library
format and include a very slim binary package.  I'm not sure what the
design philosophy *should* be, so please advise.

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

I hope so, but I want to make that a bullet item for testing.



Thanks alot for your input!  I'm glad you finally have some time for this :).

-Yaakov