Talk:PackagingDrafts/Haskell
From FedoraProject
Re: Splitting up the packages provided by GHC as a standard install
- Some libraries (like X11 until ghc-6.8.1) 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. --YaakovNemoy
- I'm not thrilled with the idea of splitting up ghc and the extralibs, because it's a pain to have to install 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. --BryanSullivan
Re: Location of actual installed libs
- Do we keep GHC installed libraries in one place, RPM installed libraries in another place, and pray that cabal keeps things organized?
- GHC puts it's packaged libraries in /usr/lib/ghc/lib. There are no conflicts. --YaakovNemoy
- Fedora is only concerned with rpm packages
- users can install their own libraries locally in their homedir if they wish.
Re: Documentation files
- 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?
- The standard for doc packages is a -doc suffix, so we're already doing the right thing. --BryanSullivan
- Haddock should pick up links across packages properly by default. --BryanSullivan
- Update: It's been pointed out that this probably already works. --YaakovNemoy
Re: build time flags or options in the cabal file.
- Some libraries take build time options via flags in cabal. Do we provide sane defaults? Both types? (This doesn't apply to trivial flags, like ones used to determine if they are compiled with the new/old versions of GHC.)
- This decision should be made on a per package basis. If a sample RPM can be built that handles options, perhaps we can look at integrating it into cabal-rpm. --YaakovNemoy
Re: profiling packages
- Other than what cabal-rpm does already, are there any rules we need for profiling packages?
- I would say no. -- YaakovNemoy
Re: devel packages
- Do we need -devel sub-packages?
- No. --BryanSullivan
Re: Naming scheme
- Package names are entirely lower case. Hackage package names should be converted. cabal-rpm does this automatically. -- YaakovNemoy
- I disagree with this: I think we should preserve case of names as usual -- JensPetersen
- I pulled this from python's playbook. I believe that it is what is generally prefered by Fedora people, rather than having RidiculousNamingSCHeMES. --Yaakov
- I agree with Yaakov's proposal to lowercase all names. The Haskell package naming capitalisation conventions are nonexistent and often ugly. -- BryanSullivan
- I disagree with this: I think we should preserve case of names as usual -- JensPetersen
Re: %postin and %preun scripts:
- Not sure about using cabal for this --JensPetersen
- What about security? As such the current system using ghc-pkg works ok and is safe.
- The scripts just invoke ghc-pkg anyways. I can't see how this makes a diffence, although i'm only suggesting this method on the inertia that cabal-rpm already does it this way. I think we can let the packaging committee comment if it is a problem.
Could the Packaging Committee comment on these issues? Please feel free to ask me any technical questions you have about Haskell internals. -YaakovNemoy
