[Fedora-haskell-list] Progress Update: 17th February 2008
by Yaakov Nemoy
Hey List,
I've been doing some work on the haskell guidelines this weekend.
* Some of the comments from this list that seemed relevant to
guidelines directly have been copied over and attributed
* Some of the comments have been properly attributed
* The guidelines have been edited for clarity or based on new knowledge
* I have some minor patches for cabal-rpm to fix a few of the random
criticisms I've received, i'll send them up in a bit
* I've repackaged zlib as a sample library package, and updated the
review request to reflect this
* I have not yet packaged the newest version of xmonad. Hopefully
I'll have this done before my trip :/
* Probably other stuff I just can't remember
Anyways, please poke around if you have the time and pass along comments.
-Yaakov
15 years, 9 months
[Fedora-haskell-list] Package guideline feedback
by 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
15 years, 10 months
[Fedora-haskell-list] ghc doesn't build under gcc43
by Jens-Ulrik Petersen
Yesterday I tried rebuilding ghc-6.8.2 for rawhide with gcc-4.3.
It got all the way to the network libray before hitting:
Socket.hsc: In function 'main':
Socket.hsc:1144: error: invalid application of 'sizeof' to incomplete
type 'struct ucred'
Socket.hsc:1144: error: invalid application of 'sizeof' to incomplete
type 'struct ucred'
Socket.hsc:1144: error: invalid application of 'sizeof' to incomplete
type 'struct ucred'
Socket.hsc:1150: error: invalid use of undefined type 'struct ucred'
Socket.hsc:1151: error: invalid use of undefined type 'struct ucred'
Socket.hsc:1152: error: invalid use of undefined type 'struct ucred'
Socket.hsc:2419: error: 'NI_MAXHOST' undeclared (first use in this function)
Socket.hsc:2419: error: (Each undeclared identifier is reported only once
Socket.hsc:2419: error: for each function it appears in.)
Socket.hsc:2420: error: 'NI_MAXSERV' undeclared (first use in this function)
compiling dist/build/Network/Socket_hsc_make.c failed
The full buildlog is
<http://koji.fedoraproject.org/koji/getfile?taskID=425959&name=build.log>.
I sent a mail to glasgow-haskell-users asking if anyone else has tried
already. Otherwise we need to fix it for f9.
Jens
15 years, 10 months
[Fedora-haskell-list] welcome
by Jens-Ulrik Petersen
Hi,
Welcome to the Fedora Haskell List of the Fedora Haskell SIG.
I thought it would be useful to have a list for discussion related to
haskell in Fedora and a forum for communication for our SIG.
I have added this list to some of the current review bugs, but the idea
is not to have this list flooded with bugzilla mails: if it gets too
overwhelming perhaps we need to rethink that or even great a separate
list for bugs.
I guess the main initial focus should be agreeing on the packaging
guidelines that Yaakov has started to draft and at the same starting to
review some of the current submitted packages to test the draft.
Jens
15 years, 10 months