[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

AUR for GuixSD (was: GuixSD on arm (ng0))

From: Ricardo Wurmus
Subject: AUR for GuixSD (was: GuixSD on arm (ng0))
Date: Wed, 06 Jul 2016 07:19:56 +0200
User-agent: mu4e 0.9.16; emacs 24.5.1

Hi David,

> I don't see guixsd as a linux distro but more as a linux distro
> building kit.

I cannot resist… :) We see GuixSD as a variant of the GNU system.  (I
think the term “linux distro” had its run and can be retired now.)

> Also on a related issue. At some point we may want something like the
> AUR for packages that don't comply with the guix packaging guidelines
> (for example linux-firmware). Or that have few users. So if I want to
> write my own bootloader and convince my friends to use it - it should
> not be in the guix tree, but it would be nice if there were a way to
> publish my package. This is something I missed in nixos.

This already exists or doesn’t, dependent on your point of view.  Guix
honours the GUIX_PACKAGE_PATH environment variable.  Any collection of
package modules in one of the directories mentioned in that variable
will be usable by Guix.  At the institute we use this for a local
collection of packages[*].

*Anyone* can put together a repository and tell people to download it
and add it to the GUIX_PACKAGE_PATH.  It’s a lot like Ubuntu’s ppa in
that regard.  Anyone could start a “GUR” (Guix User Repository) project
and try to convince others to use it.  We prefer to have most packages
in Guix itself, though.  Packages that do not match the Free System
Distribution Guidelines (GNU FSDG), however, won’t be added to Guix
upstream and also won’t be endorsed or advertised by the Guix project.
This also means that we do not welcome recommendations to use non-free
software on the mailing lists or the #guix IRC channel.

~~ Ricardo

[*]: We do this primarily for the sake of reproducibility, secondarily
for adding packages and package variants that are not useful or cannot
be in Guix upstream.  We use an unaltered version of the Guix upstream
repository, and we have a separate package repository.

Whenever a new free software package is needed I add it on my
development branch and send a patch upstream for review.  Immediately
afterward I backport it to our separate repository.  Both repositories
are accessible on the Internet, which allows users to fully describe the
state of their profiles with three things:

- the hash-like value returned by “git describe /path/to/guix”
- the hash-like value returned by “git describe /path/to/our/guix-addon”
- a manifest

Keeping things separate allows us to describe the state fully without
having to publish a modified version of the full Guix repository.  Other
scientists can just take the two repositories and reset them to the
given hashes, and then instantiate the manifest.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]