guix-play/TODO
Ludovic Courtès da0a26d2a7 Update `TODO'.
2013-03-27 00:11:57 +01:00

166 lines
5.6 KiB
Org Mode
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

-*- mode: org; coding: utf-8; -*-
Copyright © 2012, 2013 Ludovic Courtès <ludo@gnu.org>
Copying and distribution of this file, with or without modification,
are permitted in any medium without royalty provided the copyright
notice and this notice are preserved.
* integrate needed Nix code
** Remove dependency on OpenSSL
The openssl command-line tool is used in libstore to sign store paths
to be exported, and to check such signatures. The signing keys are
usually in /etc/nix/signing-key.{pub,sec}. They are a PKCS#8-encoded
X.509 SubjectPublicKeyInfo. These can be decoded with the [[http://lists.gnu.org/archive/html/help-gnutls/2012-12/msg00012.html][C API of
GnuTLS]], but not yet with its Guile bindings. Theres also
gnutls_privkey_sign_data to sign, and related functions.
** Add a binary cache substituter
Like scripts/download-from-binary-cache.pl in Nix, but written in
Scheme. Substituters allow pre-built binaries to be downloaded when
they are available from a trusted source.
** MAYBE Add a substituter that uses the GNUnet DHT
Would be neat if binaries could be pushed to and pulled from the GNUnet
DHT. Guix users would sign their binaries, and define which binaries
they trust.
** Add a remote build hook
Like scripts/build-remote.pl in Nix.
* infrastructure
** have a Hydra instance build Guix packages
[[http://nixos.org/hydra/][Hydra]] is a continuous integration tool based on Nix. It now has
[[https://github.com/NixOS/hydra/commit/f27ae1d5663680400cb99cfb898970f34d8d21be][Guile/Guix support]], which allows “build recipes” written in Guile using
Guix to be used directly on Hydra.
For a start, we may use the instance at hydra.nixos.org, generously
provided by TU Delft. However, in the future, we may want to setup our
own instance at gnu.org.
* user interface
** Add a package.el (Emacs) back-end
Unfortunately package.el is monolithic, so most likely wed have to
write a new one based on it, as opposed to actually using it.
* extend <origin>
** add OpenPGP signatures:
(origin
(method http-fetch)
(uri "http://.../foo.tgz")
(signature-uri (string-append uri ".sig"))
(signer-openpgp-fingerprint "..."))
** allow <origin> to be a derivation/package or a file
* extend <package>
** add support for search-paths
This should be passed to the build system, to extend package-specific
search path environment variableslike GUILE_LOAD_PATH, PERL5LIB,
etc.
** add a user-environment-hook
This should specify builder code to be run when building a user
environment with guix-package. For instance, Texinfos hook would
create a new dir.
** add patches there
** extend propagated-build-inputs with support for multiple outputs
#+BEGIN_SRC scheme
(outputs '("out" "include"))
(propagated-build-inputs
`(((("i1" ,p1 "o1")
("i2" ,p2))
=> "include")
("i3" ,p3)))
#+END_SRC
* synchronize package descriptions with the [[http://directory.fsf.org][FSD]] and/or the Womb
Meta-data for GNU packages, including descriptions and synopses, can be
dumped from the FSD:
http://directory.fsf.org/wiki?title=GNU/Export&action=purge .
We could periodically synchronize with that.
The [[./guix/gnu-maintenance.scm][Womb]] also contains synopses for all the GNU packages.
* support cross-compilation
Implement package-cross-derivation, and add the corresponding code in
gnu-build-system. Then, actually bootstrap a cross-compilation
environmente.g., a cross-GNU environment.
* add a guildhall build system
The Guildhall is Guiles packaging system. It should be easy to add a
guildhall-build-system that does the right thing based on guildhall
recipes.
* gnu-build-system: produce a debug derivation
Set a .gnu_debuglink in the main derivations to point to the sibling
file name (only the basename, to not retain a dependency on the debug
derivation.)
For /nix/store/xyz-foobar/bin/foo, we should have
/nix/store/abc-foobar-debug/lib/nix/store/xyz-foobar/bin/foo.debug (info
"(gdb) Separate Debug Files").
Users should have a default GDB setting with ~/.guix-profile/lib/debug
as their debug-file-directory.
* build-expression->derivation: define `%system' in the builder
Would allow build expressions to have system-dependent code, like
`glibc-dynamic-linker'.
* add allowed-references in <package>
[[file:~/src/nix/src/libstore/build.cc::if%20(drv.env.find("allowedReferences")%20!%3D%20drv.env.end())%20{][See how Nix implements that internally]].
* union
Support sophisticated collision handling when building a union: check
whether the colliding files are identical, honor per-package priorities,
etc.
* guix package
** add --list-generations, and --delete-generations
* guix build utils
** Add equivalent to Nixpkgs's wrapProgram
** MAYBE Change ld-wrapper to add RPATH for libs passed by file name
** MAYBE Add equivalent to chrpath, possibly using [[https://gitorious.org/guile-dlhacks/guile-dlhacks/][guile-dlhacks]]
** MAYBE Add a hash-rewriting thing for deep dependency replacement without rebuild
See [[https://github.com/NixOS/nixpkgs/commit/d1662d715514e6ef9d3dc29f132f1b3d8e608a18][Shea Levy's `replace-dependency' in Nixpkgs]].
* distro
** port to new GNU/Linux platforms, notably mipsel64-linux
** port to GNU/Hurd, aka. i686-gnu
Problems include that current glibc releases do not build on GNU/Hurd.
In addition, there havent been stable releases of GNU Mach, MiG, and
Hurd, which would be a pre-condition.
** make a bootable GNU/Linux-Libre distro, with OS configuration EDSL
Similar in spirit to /etc/nixos/configuration.nix.