From Fedora Project Wiki
(New page: * 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 ...)
 
Line 1: Line 1:
 
* 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?
 
* 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 would love to do this. --YaakovNemoy
** I'm not thrilled with the idea of splitting up ghc and the extralibs,
+
** 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
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. --BryanSullivan
 
 
* Do we keep GHC installed libraries in one place, RPM installed libraries in another place, and pray that cabal keeps things organized?
 
* 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
 
** GHC puts it's packaged libraries in /usr/lib/ghc/lib.  There are no conflicts. --YaakovNemoy

Revision as of 18:11, 2 July 2008

  • 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
  • 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.
  • 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
  • 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
  • Other than what cabal-rpm does already, are there any rules we need for profiling packages?
    • I would say no. -- YaakovNemoy
  • Do we need -devel sub-packages?
    • No. --BryanSullivan
  • 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

Could the Packaging Committee comment on these issues? Please feel free to ask me any technical questions you have about Haskell internals. -YaakovNemoy