GHC 6.10.1 will be the last release that ships with extralibs, the "metapackage" of libraries that has been comaintained with GHC since forever.
In fact, extralibs will be obsoleted within the lifetime of GHC 6.10.1. Its replacement, the Haskell Platform, should be released within a month after 6.10.1 itself. The Platform will develop and be maintained on a schedule independent of GHC, so it no longer makes sense to tie the two together.
Since GHC without extralibs/Platform is completely useless for practical development, we need to sort out a strategy for this pretty soon.
One simple possibility: split the ghc package up now. Initially create a "ghc-platform" subpackage in the same spec file, containing extralibs. Make the ghc package depend on ghc-platform, so it will be autoinstalled by a depsolver. When the real platform is released, split ghc into toplevel ghc and ghc-platform packages, chop out the ghc-platform subpackage from the ghc spec file, but don't rebuild the ghc package (since not necessary). A build of the new ghc-platform package should supersede the old subpackage (since rpm itself doesn't seem to know about subpackages at all). Someone installing ghc after the splitup should get the old ghc and the new ghc-platform.
Does this sound reasonable? The only actions required from anyone else in the next week or two are to (a) state an opinion on this and, if it's generally positive (b) for someone to review a placeholder ghc-package review request, so we can crank in a timely manner when the final platform is released.
On Sun, Oct 12, 2008 at 5:22 PM, Bryan O'Sullivan bos@serpentine.com wrote:
GHC 6.10.1 will be the last release that ships with extralibs, the "metapackage" of libraries that has been comaintained with GHC since forever.
In fact, extralibs will be obsoleted within the lifetime of GHC 6.10.1. Its replacement, the Haskell Platform, should be released within a month after 6.10.1 itself. The Platform will develop and be maintained on a schedule independent of GHC, so it no longer makes sense to tie the two together.
Since GHC without extralibs/Platform is completely useless for practical development, we need to sort out a strategy for this pretty soon.
One simple possibility: split the ghc package up now. Initially create a "ghc-platform" subpackage in the same spec file, containing extralibs. Make the ghc package depend on ghc-platform, so it will be autoinstalled by a depsolver. When the real platform is released, split ghc into toplevel ghc and ghc-platform packages, chop out the ghc-platform subpackage from the ghc spec file, but don't rebuild the ghc package (since not necessary). A build of the new ghc-platform package should supersede the old subpackage (since rpm itself doesn't seem to know about subpackages at all). Someone installing ghc after the splitup should get the old ghc and the new ghc-platform.
Does this sound reasonable? The only actions required from anyone else in the next week or two are to (a) state an opinion on this and, if it's generally positive (b) for someone to review a placeholder ghc-package review request, so we can crank in a timely manner when the final platform is released.
+1
haskell-devel@lists.fedoraproject.org