[Pkg-haskell-commits] darcs: policy: Completed first draft

Ian Lynagh igloo at earth.li
Fri Nov 5 15:02:28 UTC 2010


Sun Jul 25 20:46:22 UTC 2004  Ian Lynagh <igloo at earth.li>
  * Completed first draft

    M ./haskell-policy.sgml -17 +140

Sun Jul 25 20:46:22 UTC 2004  Ian Lynagh <igloo at earth.li>
  * Completed first draft
diff -rN -u old-policy/haskell-policy.sgml new-policy/haskell-policy.sgml
--- old-policy/haskell-policy.sgml	2010-11-05 15:02:27.540805242 +0000
+++ new-policy/haskell-policy.sgml	2010-11-05 15:02:27.556806087 +0000
@@ -1,11 +1,18 @@
 <!doctype debiandoc public "-//DebianDoc//DTD DebianDoc//EN"
 [
 <!entity version "0.1.0">
-<!entity must   "<em>must</em>">
-<!entity should "<em>should</em>">
-<!entity may    "<em>may</em>">
-<!entity mailinglist      "Haskell mailing list">
-<!entity mailinglistemail "<email>debian-haskell at lists.urchin.earth.li</email>">
+<!entity must      "<em>must</em>">
+<!entity mustnot   "<em>must not</em>">
+<!entity should    "<em>should</em>">
+<!entity shouldnot "<em>should not</em>">
+<!entity haskellexperimental
+    "<qref id=&#34;haskellexperimental&#34;>Haskell Experimental</qref>">
+<!entity mailinglist
+    "<qref id=&#34;mailinglist&#34;>Haskell mailing list</qref>">
+<!entity mailinglistemail
+    "<email>debian-haskell at lists.urchin.earth.li</email>">
+<!entity mailinglisthttpaddress
+    "http://urchin.earth.li/mailman/listinfo/debian-haskell">
 ]
 >
 
@@ -76,18 +83,29 @@
         </p>
 
         <p>
-            We use &may;, &should; and &must; as defined in
-            <prgn>RFC 2119</prgn>.
+            We use &should;, &shouldnot;, &must; and &mustnot; as
+            defined in <prgn>RFC 2119</prgn>.
         </p>
 
         <sect id="mailinglist">
         <heading>Mailing List</heading>
         <p>
-            There is a &mailinglist; for Debian Haskell discussions. The
+            There is a mailing list for Debian Haskell discussions. The
             address to post to is &mailinglistemail;, and information on
             (un)subscribing and archives is at
-            <url id="http://urchin.earth.li/mailman/listinfo/debian-haskell"
-                 name="the list homepage">.
+            <url id="&mailinglisthttpaddress;" name="the list homepage">.
+        </p>
+
+        <sect id="haskellexperimental">
+        <heading>Haskell Experimental apt repository</heading>
+        <p>
+            <url id="http://www.syntaxpolice.org/haskell-experimental/haskell-experimental.html"
+                 name="Haskell Experimental"> is an apt repository for
+            Debian packages that are not suitable for uploading to
+            Debian. For example, they may be software in the early
+            phases of development or backports of software to stable.
+            See the above page for details of how to get upload access
+            to it.
         </p>
     </chapt>
 
@@ -97,8 +115,14 @@
         <sect id="usr-bin-haskell-compiler">
         <heading><file>/usr/bin/haskell-compiler</file></heading>
         <p>
-            All Haskell compilers &should; provide a
-            <file>/usr/bin/haskell-compiler</file> that:
+            All Haskell compilers &should; provide the
+            <prgn>haskell-compiler</prgn> virtual package and a
+            <file>/usr/bin/haskell-compiler</file>.
+            {XXX The virtual package doesn't currently exist}
+            Packages &mustnot;
+            provide one of these but not the other.
+            The <file>/usr/bin/haskell-compiler</file> must handle
+            argument as follows:
             <enumlist>
                 <item>
                     If given an argument <var>x</var><tt>.hs</tt> or
@@ -154,6 +178,7 @@
             then this &must; compile programs according to the
             <url id="http://www.haskell.org/definition/"
                  name="Haskell 98 Report (Revised) and Approved Addenda">.
+            {XXX This is a moving target. What should we do about it?}
         </p>
 
         <p>
@@ -173,7 +198,8 @@
         <sect id="haskell-utils">
         <heading><prgn>haskell-utils</prgn></heading>
         <p>
-            Register with <prgn>haskell-utils</prgn> XXX
+            All Haskell implementation &should; register with
+            <prgn>haskell-utils</prgn>. See its manpage for details.
         </p>
         </sect>
     </chapt>
@@ -181,16 +207,113 @@
     <chapt id="libraries">
         <heading>Haskell Libraries</heading>
         <p>
-            Names. Compiler deps. Mention alternate (install time
-            compilation) possibility.
+            It is strongly recommended that only
+            <url id="http://www.haskell.org/cabal/" name="cabalised">
+            libraries are packaged. If you wish to package a
+            non-cabalised library then the recommended approach is to
+            first cabalise it, forwarding the patch upstream.
+        </p>
+
+        <p>
+            {XXX we need a mapping from cabal names to package names.
+            We (Debian) need a name matching (case sensitive)
+            [a-z0-9][-+.a-z0-9]+
+            If cabal uses [a-z0-9][-a-z0-9]* this is easy (id).
+            If cabal uses [a-zA-Z0-9][a-zA-Z0-9]* then perhaps
+            fooBar -&gt; foo-bar. Or foobar? What should FooBar map to?
+            If cabal allows both uppercase and - then what do we do?
+            Just lowercase everything and assume there won't be
+            collisions?
+            }
+        </p>
+
+        <p>
+            If the name given by the above rules is <var>cname</var>
+            then the Debian source package should be called
+            <tt>lib</tt><var>cname</var> and, for each implementation
+            <var>impl</var> that it is built for, it should make a
+            <tt>lib</tt><var>impl</var><tt>-</tt><var>cname</var> binary
+            package.
+        </p>
+
+        <p>
+            If multiple cabal packages are in a single upstream tarball,
+            and repacking them separately does not seem sensible then
+            a sensible source package name should be chosen.
+            A separate binary package for each cabal package, following
+            the naming scheme above, &should; still be created.
+        </p>
+
+        <p>
+            Some Haskell compilers, such as GHC, perform cross-module
+            optimisations, such as inlining.
+            This means that even small
+            internal changes to a library <var>foo</var> can cause
+            programs that link with a library <var>bar</var> which links
+            uses <var>foo</var> to fail to link, or even to link
+            successfully but give incorrect results.
+            Therefore libraries &must; depend on the exact version of
+            other Haskell libraries that they were compiled against.
+            Furthermore, they must build-depend on the exact version of
+            the Haskell libraries they use in order to keep the packages
+            in sync across all arches.
+        </p>
+
+        <p>
+            An exception is made for the libraries shipped with
+            compilers. The reasons for this are:
+            <list>
+                <item>
+                    Many of the libraries currently shipped with
+                    compilers will be used by very few libraries.
+                    Should a library need to be changed in a Debian
+                    release the compiler package &must; conflict with
+                    those packages affected.
+                </item>
+                <item>
+                    While an upload of a library to fix other packaging
+                    issues will result in only a handful, at most, of
+                    packages needing to be (needlessly) recompiled, such
+                    an upload of a compiler would require all libraries
+                    to be (needlessly) recompiled.
+                </item>
+            </list>
+            Thus we believe this policy gives the best tradeoff between
+            maintainers having to be careful about conflicts when they
+            make changes and not wasting too many CPU cycles on
+            unnecessary recompilation.
+        </p>
+
+        <p>
+            The possibility of compiling libraries at install time was
+            considered, but was rejected due to its fragility and due to
+            it being against the spirit of Debian being a binary
+            districution.
+        </p>
+
+        <p>
+            All libraries &should; be built for all released compilers in
+            Debian for which they are buildable. Libraries &shouldnot;
+            be built for unreleased compilers, such as CVS snapshots,
+            without good reason, as uploads of new versions of these
+            would require new uploads of all such libraries, and their
+            reverse dependencies, too. However, you can upload libraries
+            built against unreleased compilers to &haskellexperimental;.
         </p>
     </chapt>
 
     <chapt id="programs">
         <heading>Haskell Programs</heading>
         <p>
-            Names. Compiler deps. Mention alternate (install time
-            compilation) possibility.
+            As with libraries, the recommended was of packaging Haskell
+            programs is to first cabalise them if they are not already
+            cabalised. The package name, both binary and source, should
+            then be derived from the cabal package name in the same way
+            as for libraries. Programs needing Haskell 98 and approved
+            addenda only &should; use
+            <file>/usr/bin/haskell-compiler</file> to build. Otherwise,
+            your package should build-depend on suitable compilers,
+            prefering those that produce better code.
         </p>
     </chapt>
 </book>





More information about the Pkg-haskell-commits mailing list