Changes between Version 25 and Version 26 of HackageToDo

Timestamp:

07/25/07 17:58:17 (6 years ago)

Author:

ross@…

Comment:

update haddock, refine attributes

HackageToDo

@@ -7 +7 @@
 
 Currently:
+ * As part of [http://hackage.haskell.org/trac/summer-of-code/wiki/SoC2007Hackage a Google Summer of Code project],
+   Sascha Böhme is implementing a tool to build HackageDB packages using Cabal
+   in a chroot jail.
+    * Building using Cabal is more likely to work than some shortcut, and performs a
+      useful test on the package.
+    * For this to work, prerequisite packages must be built, haddocked and
+      installed first.
+    * The chroot jail is needed because Cabal builds can invoke arbitrary code.
+    * The alternative of only building packages that use the simple build system
+      would rule out too many important packages.
+ * Trials are being run, generating documentation and build logs for the library
+   packages in HackageDB.
+   Soon it will run automatically.
  * [http://www.haskell.org/haddock/ Haddock] documentation for a library package is
    placed in the directory ''archive''`/`''pkg''`/`''version''`/doc/html`.
@@ -12 +25 @@
    to the documentation for the corresponding modules.
  * The haddock documentation links to types, modules etc. in the packages it depends on.
- * Links across packages always point to the latest version of the target package.
+ * Links across packages point to the latest version of the target package, unless
+   the dependency has a constraint that forbids this.
    This way we don't have to worry about re-haddocking dependent packages whenever
    a package at the bottom of the tree is updated.
-   Some dependencies may go wrong, if a package depends on a specific version of
-   another package for example, but this way is simple at least.
  * The `--html-location` option of the development version of Cabal is used to make
    haddock generate links pointing at ''archive''`/`''pkg''`/latest/doc/html`,  
    which will be a symbolic link to an `html` directory.
- * Some trial runs have been made, generating documentation for some packages.
-The missing part is automatic generation of the documentation.
-Some possibilities:
- * Avoid running arbitrary code to generate the Haddock by restricting ourselves
-   to packages that just use the simple build system and only Haddock those, then we don't
-   need to worry about arbitrary code.  But some important packages use autoconf, and
-   we won't be able to do those.  We could use the new `Build-Type` field to tell us
-   whether a package uses the simple build system or not.
- * We could use Cabal to build the Haddock docs, but then prerequisite packages must be
-   configured, built, haddocked and installed (in a local package database), so we would
-   not be able to avoid running arbitrary code.
-   To be safe, this could be done in a chroot jail.
-The latter choice seems cleanest.
+ * The build log for a package is placed in the file
+   ''archive''`/`''pkg''`/`''version''`/log`.
+   If this file exists, the package script displays a link to it.
 
 Should building happen during upload, between upload and arriving in the archive, or later?
@@ -41 +43 @@
 
 Other things we could do:
- * Link to the build log from the package page.
  * Generate a [http://www.haskell.org/hoogle Hoogle] database for searching.
  * Syntax highlighted source code (using
@@ -54 +55 @@
 There will be a need to add other attributes of uploaded packages, without modifying
 the .cabal file.
-This could be achieved with a plain text tags file, outside of the Cabal package,
-providing a mapping from attributes to values (both strings).
+This could be achieved by storing a mapping from attributes to values (both strings) outside of the Cabal package.
+(Suggested format: a plain text file with a mail header format like the .cabal file.)
+These attributes could be set by programs on the server, set by users via a web interface, shown by the package display and used for searching.
+
 Example attributes:
  * who uploaded the package
@@ -63 +66 @@
  * user-supplied descriptions of the package
  * feedback from users' [wiki:CabalInstall cabal-install] runs (?)
-These attributes could be shown by the package display and used for searching.
+ * overriding fields from the .cabal file, e.g. `category`
 
-They could also be used for a more sophisticated form of classification,
+These attributes could also be used for a more sophisticated form of classification,
 as in [http://debtags.alioth.debian.org/ debtags],
 but multiple categories should be enough for now.