Matt <m...@excalamus.com> writes:
> My guess, as Guix is a package manager, there are two audiences: > package users (end users) and package maintainers. I'm curious what > degree of separation between those should exist for Guix. On of the goals of the GNU project is to give users the tools to liberate themselves from arbitrary restrictions. The Hurd pretty much does away with the concept of an all-powerful root user as the only privileged account to alter settings such as network, file system virtualization, drivers, etc. Emacs is designed to be a collection of extensions. Guile was designed to be the extension language for every part of the GNU system that was still constrained by the dead systems programming language C. Likewise, Guix aims to give “end users” control over their software environments and systems, privileges that used to be reserved for the sysadmin class. All design decisions in Guix are aimed at extending privileges to users: package transformations, package inheritance, building packages from JSON descriptions for those averse to Scheme, per-user channels, time machine, an extensive API to build and export systems, virtual machines, containers, environments, etc. We don’t like to erect arbitrary boundaries between “end users” and maintainers. The concept of “maintainer” only ever has meaning in the context of project management. (Unlike nixpkgs, for example, we don’t record package maintainers with package definitions.) So, ideally, the information in the manual / cookbook will benefit all users, no matter how deep they want to dive. A single document cannot accomplish this, which is why we recognize the existence of other GNU manuals and link to them where possible. -- Ricardo