Skip to content


Subversion checkout URL

You can clone with
Download ZIP
tree: 532ef64a34
Fetching contributors…

Cannot retrieve contributors at this time

499 lines (427 sloc) 16.727 kb
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "">
<html xmlns="" xml:lang="en" lang="en">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="generator" content="Docutils 0.4:" />
<title>GHC 6.6 Launch</title>
<meta name="author" content="Lennart Kolmodin &lt;kolmodin&#64;;, Gentoo Haskell Herd &lt;haskell&#64;;" />
<style type="text/css">
:Author: David Goodger
:Date: $Date: 2005-12-18 01:56:14 +0100 (Sun, 18 Dec 2005) $
:Revision: $Revision: 4224 $
:Copyright: This stylesheet has been placed in the public domain.
Default cascading style sheet for the HTML output of Docutils.
See for how to
customize this style sheet.
/* used to remove borders from tables and images */
.borderless, table.borderless td, table.borderless th {
border: 0 }
table.borderless td, table.borderless th {
/* Override padding for "table.docutils td" with "! important".
The right padding separates the table cells. */
padding: 0 0.5em 0 0 ! important }
.first {
/* Override more specific margin styles with "! important". */
margin-top: 0 ! important }
.last, .with-subtitle {
margin-bottom: 0 ! important }
.hidden {
display: none }
a.toc-backref {
text-decoration: none ;
color: black }
blockquote.epigraph {
margin: 2em 5em ; }
dl.docutils dd {
margin-bottom: 0.5em }
/* Uncomment (and remove this text!) to get bold-faced definition list terms
dl.docutils dt {
font-weight: bold }
div.abstract {
margin: 2em 5em }
div.abstract p.topic-title {
font-weight: bold ;
text-align: center }
div.admonition, div.attention, div.caution, div.danger, div.error,
div.hint, div.important, div.note, div.tip, div.warning {
margin: 2em ;
border: medium outset ;
padding: 1em }
div.admonition p.admonition-title, div.hint p.admonition-title,
div.important p.admonition-title, div.note p.admonition-title,
div.tip p.admonition-title {
font-weight: bold ;
font-family: sans-serif }
div.attention p.admonition-title, div.caution p.admonition-title,
div.danger p.admonition-title, div.error p.admonition-title,
div.warning p.admonition-title {
color: red ;
font-weight: bold ;
font-family: sans-serif }
/* Uncomment (and remove this text!) to get reduced vertical space in
compound paragraphs.
div.compound .compound-first, div.compound .compound-middle {
margin-bottom: 0.5em }
div.compound .compound-last, div.compound .compound-middle {
margin-top: 0.5em }
div.dedication {
margin: 2em 5em ;
text-align: center ;
font-style: italic }
div.dedication p.topic-title {
font-weight: bold ;
font-style: normal }
div.figure {
margin-left: 2em ;
margin-right: 2em }
div.footer, div.header {
clear: both;
font-size: smaller }
div.line-block {
display: block ;
margin-top: 1em ;
margin-bottom: 1em }
div.line-block div.line-block {
margin-top: 0 ;
margin-bottom: 0 ;
margin-left: 1.5em }
div.sidebar {
margin-left: 1em ;
border: medium outset ;
padding: 1em ;
background-color: #ffffee ;
width: 40% ;
float: right ;
clear: right }
div.sidebar p.rubric {
font-family: sans-serif ;
font-size: medium }
div.system-messages {
margin: 5em }
div.system-messages h1 {
color: red }
div.system-message {
border: medium outset ;
padding: 1em }
div.system-message p.system-message-title {
color: red ;
font-weight: bold }
div.topic {
margin: 2em }
h1.section-subtitle, h2.section-subtitle, h3.section-subtitle,
h4.section-subtitle, h5.section-subtitle, h6.section-subtitle {
margin-top: 0.4em }
h1.title {
text-align: center }
h2.subtitle {
text-align: center }
hr.docutils {
width: 75% }
img.align-left {
clear: left }
img.align-right {
clear: right }
ol.simple, ul.simple {
margin-bottom: 1em }
ol.arabic {
list-style: decimal }
ol.loweralpha {
list-style: lower-alpha }
ol.upperalpha {
list-style: upper-alpha }
ol.lowerroman {
list-style: lower-roman }
ol.upperroman {
list-style: upper-roman }
p.attribution {
text-align: right ;
margin-left: 50% }
p.caption {
font-style: italic }
p.credits {
font-style: italic ;
font-size: smaller }
p.label {
white-space: nowrap }
p.rubric {
font-weight: bold ;
font-size: larger ;
color: maroon ;
text-align: center }
p.sidebar-title {
font-family: sans-serif ;
font-weight: bold ;
font-size: larger }
p.sidebar-subtitle {
font-family: sans-serif ;
font-weight: bold }
p.topic-title {
font-weight: bold }
pre.address {
margin-bottom: 0 ;
margin-top: 0 ;
font-family: serif ;
font-size: 100% }
pre.literal-block, pre.doctest-block {
margin-left: 2em ;
margin-right: 2em ;
background-color: #eeeeee }
span.classifier {
font-family: sans-serif ;
font-style: oblique }
span.classifier-delimiter {
font-family: sans-serif ;
font-weight: bold }
span.interpreted {
font-family: sans-serif }
span.option {
white-space: nowrap }
span.pre {
white-space: pre }
span.problematic {
color: red }
span.section-subtitle {
/* font-size relative to parent (h1..h6 element) */
font-size: 80% }
table.citation {
border-left: solid 1px gray;
margin-left: 1px }
table.docinfo {
margin: 2em 4em }
table.docutils {
margin-top: 0.5em ;
margin-bottom: 0.5em }
table.footnote {
border-left: solid 1px black;
margin-left: 1px }
table.docutils td, table.docutils th,
table.docinfo td, table.docinfo th {
padding-left: 0.5em ;
padding-right: 0.5em ;
vertical-align: top }
table.docutils th.field-name, table.docinfo th.docinfo-name {
font-weight: bold ;
text-align: left ;
white-space: nowrap ;
padding-left: 0 }
h1 tt.docutils, h2 tt.docutils, h3 tt.docutils,
h4 tt.docutils, h5 tt.docutils, h6 tt.docutils {
font-size: 100% }
tt.docutils {
background-color: #eeeeee } {
list-style-type: none }
<div class="document" id="ghc-6-6-launch">
<h1 class="title">GHC 6.6 Launch</h1>
<table class="docinfo" frame="void" rules="none">
<col class="docinfo-name" />
<col class="docinfo-content" />
<tbody valign="top">
<tr><th class="docinfo-name">Author:</th>
<td>Lennart Kolmodin &lt;<a class="reference" href="mailto:kolmodin&#64;">kolmodin&#64;</a>&gt;,
Gentoo Haskell Herd &lt;<a class="reference" href="mailto:haskell&#64;">haskell&#64;</a>&gt;</td></tr>
<tr class="field"><th class="docinfo-name">Updated:</th><td class="field-body">2007-07-23</td>
<p>Due to the restructure of bundled libraries from GHC 6.4 -&gt; 6.6 we've had to
rewrite ebuild dependencies between packages and libraries. While doing this
we have also taken the chance to do some updates we've been ponding on in
the past.</p>
<p>This document describes some background on what's new in GHC 6.6 and the
plan that has been carefully crafted on how to deal with it.</p>
<p>We have tried to summarize what the Gentoo Haskell Heard has been up to the
past months (or year...).</p>
<div class="section">
<h1><a id="introduction" name="introduction">1&nbsp;&nbsp;&nbsp;Introduction</a></h1>
<p>In GHC 6.4 a lot of packages where bundled with the compiler. In GHC 6.6
this has changed, all but the packages used by the compiler itself are now
available as a separate download. That bundle is called ghc-extralibs.</p>
<p>This makes the GHC installation much faster, as you only compile the libs
you need. Also, it gives the advantage that when you'd like to update a
library, you only have to recompile exactly that one, instead of recompiling
everything like before.</p>
<p>We have also merged the dev-lang/ghc-bin package into the dev-lang/ghc
package, which you can get by using <tt class="docutils literal"><span class="pre">USE=binary</span></tt>. The ghc-bin tarball is
used to bootstrap the source ghc compiler, instead of relying on a
preinstalled compiler.</p>
<p>This can be modeled in Gentoo Linux' package management system, as
we'll see next.</p>
<div class="section">
<h1><a id="the-plan" name="the-plan">2&nbsp;&nbsp;&nbsp;The plan</a></h1>
<p>Each library in the ghc-extralibs will be represented by a separate
package in the tree. Packages that can be compiled with GHC 6.6 (possibly
also GHC 6.4) should depend on the modular libraries.</p>
<p>To mirror this behavior for GHC 6.4 where the compiler already provides the
libraries, we use dummy libraries as place holders. They will not do or
install anything, but merely exist to depended upon by packages that need
those libraries. The dummy libraries will only depend on the GHC 6.4
compiler, while the real modular libs will depend on the GHC 6.6 series or
newer. If an application/library is compiled against GHC 6.4 the dummy
libraries will be used, and in the case of GHC 6.6 the modular libraries.
This way it'll be easy to write the ebuilds, just depend on the libraries
you need, regardless of compiler version.</p>
<p>Note though, packages that cannot be built with GHC 6.6 doesn't gain
anything from depending on the modular libraries, as they are guarantied to
all be dummy libraries. Thus there should be no requirement for those
packages to use the modular libs.</p>
<div class="section">
<h1><a id="why-merge-ghc-and-ghc-bin" name="why-merge-ghc-and-ghc-bin">3&nbsp;&nbsp;&nbsp;Why merge ghc and ghc-bin?</a></h1>
<p>It makes dependienceies simpler...:</p>
<pre class="literal-block">
DEPEND=&quot;=virtual/ghc-6.4* !&gt;=virtual/ghc-6.6&quot;
<p>Assume the user has ghc-bin-6.4.2 which he (or she!) used to compile
ghc-6.4.2, and then one day installs ghc-6.6. The first dependency will be
satisfied by ghc-bin-6.4.2, but it's actually ghc-6.6 that's going to be
used to compile the package! (as ghc has precedence to ghc-bin). The block
makes sure this doesn't happen.</p>
<p>With ghc only available as one package, you can simply say:</p>
<pre class="literal-block">
<div class="section">
<h1><a id="step-by-step" name="step-by-step">4&nbsp;&nbsp;&nbsp;Step by step</a></h1>
<p>The proposed actions of the scheme are listed below.</p>
<div class="section">
<h2><a id="add-ghc-6-6-to-the-tree" name="add-ghc-6-6-to-the-tree">4.1&nbsp;&nbsp;&nbsp;Add GHC 6.6 to the tree</a></h2>
<p>This was done 7 March. It's p.masked.</p>
<div class="section">
<h2><a id="ghc-bin" name="ghc-bin">4.2&nbsp;&nbsp;&nbsp;ghc-bin</a></h2>
<p>Update 2007-03-16: ghc-bin-6.6 in the tree, ~amd64 ~x86</p>
<p>Update 2007-04-12: cparrot has added ~alpha, ~ppc and ~sparc</p>
<dl class="docutils">
<dt>Update 2007-07-23: the ghc-bin tarballs are usable, but the packages will go</dt>
<div class="section">
<h2><a id="add-modular-libs" name="add-modular-libs">4.3&nbsp;&nbsp;&nbsp;Add modular libs</a></h2>
<p>Ie, only the modular libs from ghc-extralibs meant for GHC 6.6. They should
also be p.masked.</p>
<p>Modular libs has been added for:</p>
<ul class="simple">
<p>Still missing for:</p>
<ul class="simple">
<div class="section">
<h2><a id="add-dummy-libs" name="add-dummy-libs">4.4&nbsp;&nbsp;&nbsp;Add dummy libs</a></h2>
<p>The about 15 packages of ghc-extralibs has to be modeled as dummy libs
too. They should be added as ~arch and then be stabilized by the arch teams
<p>The most common libs where added the 11th March, and have been marked as
~arch or stable on 2007-04-02:</p>
<ul class="simple">
<p>Dummies missing, just as all dummies, they only has to be added if an ebuild
depends on that functionality:</p>
<ul class="simple">
<div class="section">
<h2><a id="start-rewrite-other-libs-and-apps-to-use-the-dummy-libs" name="start-rewrite-other-libs-and-apps-to-use-the-dummy-libs">4.5&nbsp;&nbsp;&nbsp;Start rewrite other libs and apps to use the dummy libs</a></h2>
<p>This is only required for applications that can be compiled with GHC 6.6, as
described above.</p>
<p>Packages that today are marked as stable and can be compiled with GHC 6.6
requires that the dummy libraries are marked as stable too. Thus we have to
start rewriting the other packages until the dummys has been marked stable.</p>
<div class="section">
<h2><a id="make-new-libs-use-the-p-masked-modular-libs" name="make-new-libs-use-the-p-masked-modular-libs">4.6&nbsp;&nbsp;&nbsp;Make new libs use the p.masked modular libs</a></h2>
<p>Packages that only compiles with GHC 6.6 can be added to, if p.masked.</p>
<div class="section">
<h2><a id="p-unmasking" name="p-unmasking">4.7&nbsp;&nbsp;&nbsp;p.unmasking</a></h2>
<ul class="simple">
<li>update ghc-6.6.1 ebuild in portage from the overlay version</li>
<li>update ghc and cabal eclasses in portage from the overlay versions</li>
<li>merge any changes in the modular libs from the overlay</li>
<li>unmask ghc-6.6.1 and associated modular libs</li>
<li>put combined ghc-6.4.2 and 6.2.2 ebuilds into portage</li>
<li>mask ghc-bin asking people to move to ghc with USE=binary</li>
<li>make all other ebuilds depend on dev-lang/ghc rather than virtual/ghc</li>
<li>remove ghc-bin and the ghc virtual</li>
<!-- cleaned up conversation from 2007-03-01
20:15 < dcoutts_> sure sure
20:15 < dcoutts_> so we should add dummy packages now
20:15 < dcoutts_> I think at the same time we should get ghc-6.6 into portage p.masked
20:16 < dcoutts_> so at least the arch teams will see our plan
20:16 < dcoutts_> and the necessity to mark the dummy things stable
20:16 < dcoutts_> and it'll make it easier to test things in the context of portage rather than the overlay
20:16 < dcoutts_> we could also add new libs p.masked
20:16 < dcoutts_> whatever
20:17 < dcoutts_> actually if new libs work with 6.4 they can dep on the modular libs and things should work
20:17 < dcoutts_> since the dummys will be ~arch for a while
20:18 < dcoutts_> so they would not need to be p.masked, only things which require 6.6 would need to be p.masked
20:18 < dcoutts_> like the non-dummy versions of the modular libs
20:19 < dcoutts_> so lets clarify.. what can we do now without the arch team's involvement?
20:19 < dcoutts_> 1. we can add the dummy modular libs packages in ~arch
20:19 < dcoutts_> 2. we can add ghc-6.6 p.masked
20:19 < dcoutts_> 3. we can add the real modular libs packages in p.mask
20:20 < dcoutts_> (note: so far no existing packages changed)
20:21 < dcoutts_> 4. new ~arch versions of libs/progs can dep on the dummy libs
20:21 < dcoutts_> 5. new p.masked versions of libs/progs can dep on ghc-6.6 and real libs
20:21 < dcoutts_> then I think we have to wait
20:21 < dcoutts_> we have to get the dummy libs stable
20:21 < dcoutts_> and modify existing packages to dep on them
20:23 < dcoutts_> so once the existing packages are depending on the modular libs, and are all patched up to work with ghc-6.6...
20:23 < dcoutts_> then we can unmask ghc-6.6 and the other libs depending on it
20:23 < dcoutts_> how about that?
20:23 < dcoutts_> so we never need to mark existing packages as <ghc-6.6
20:23 < dcoutts_> on the other hand it takes a bit longer to unmask 6.6
20:24 < dcoutts_> the other strategy is to unmask 6.6 earlier but modify existing packages to <ghc-6.6
20:24 < dcoutts_> that's not ideal since people upgrading will then not be able to update their existing packages
20:24 < dcoutts_> ie we'd break things
20:25 < dcoutts_> kolmodin, might want to copy it, edit it, and put it in portage as .txt/.html or something
20:25 < dcoutts_> and revise it as we refine/agree the plan
20:25 < kolmodin> aye, good idea
20:25 < dcoutts_> then we can get on with it without having to keep referring to each other about what the plan was :-) -->
Jump to Line
Something went wrong with that request. Please try again.