Mirror of GNU Guix
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

174 lines
6.0 KiB

-*- mode: org; coding: utf-8; -*-
10 years ago
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
Guix uses Nix’s daemon (‘nix-worker’, later renamed to ‘nix-daemon’) to
actually perform builds, scheduling, substitution of pre-built binaries,
and GC-related tasks. The daemon mainly uses ‘libstore’ from Nix.
Integrating it in Guix itself will make Guix self-contained, thereby
simplifying our users’ lives.
** 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. There’s also
‘gnutls_privkey_sign_data’ to sign, and related functions.
10 years ago
** 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.
10 years ago
** 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.
10 years ago
** 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.
* add guix-pull
A tool that fetches the latest code from [[http://git.savannah.gnu.org/cgit/guix.git/snapshot/guix-master.tar.gz][cgit]], builds a derivation that
unpacks it, copies only .scm files (this excludes guix/config.in) and
compiles it, and then links to it from ~/.local/guix/latest . Change
guix-build and guix-package to have that directory first in their load
10 years ago
* user interface
** Add a package.el (Emacs) back-end
Unfortunately package.el is monolithic, so most likely we’d have to
write a new one based on it, as opposed to actually using it.
* extend <origin>
** add OpenPGP signatures:
(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 variables–like ‘GUILE_LOAD_PATH’, ‘PERL5LIB’,
** add a ‘user-environment-hook’
This should specify builder code to be run when building a user
environment with ‘guix-package’. For instance, Texinfo’s hook would
create a new ‘dir’.
10 years ago
** add ‘patches’ there
** extend ‘propagated-build-inputs’ with support for multiple outputs
#+BEGIN_SRC scheme
(outputs '("out" "include"))
`(((("i1" ,p1 "o1")
("i2" ,p2))
=> "include")
("i3" ,p3)))
* support cross-compilation
Implement ‘package-cross-derivation’, and add the corresponding code in
‘gnu-build-system’. Then, actually bootstrap a cross-compilation
environment–e.g., a cross-GNU environment.
10 years ago
* add a guildhall build system
The Guildhall is Guile’s packaging system. It should be easy to add a
‘guildhall-build-system’ that does the right thing based on guildhall
* 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’
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
* 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,
* guix-package
** add ‘--roll-back’
** add ‘--list-generations’, and ‘--delete-generations’
** add ‘--upgrade’
** add ‘--search’
* guix build utils
** Add equivalent to "rm -rf"
** Add equivalent to Nixpkgs's ‘wrapProgram’
** Add equivalent to chrpath, possibly using [[https://gitorious.org/guile-dlhacks/guile-dlhacks/][guile-dlhacks]]
10 years ago
** 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
** choose a name! (Jinn?)
** 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 haven’t 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.