[Nix-dev] some ideas to (re)organize/improve nixos
Gour
gour at mail.inet.hr
Tue May 20 08:19:33 CEST 2008
Hello!
In last few days I expressed some ideas about the possibility to improve
and/or reorganize Nixos to be more user-friendly, but it seems that
#nixos is not the best medium for such talk.
At the moment I'm VM-nixos user waiting to finish some tasks prior to
putting Nixos on my laptop and then, hopefully, on my desktop machine as
well.
Now I'm using Archlinux (since July '07) and before that I was running
Gentoo for 5yrs, but will use examples mostly from Arch and there are
few areas I'll touch in this post...
1) repositories
Even before Gentoo, when using SuSE, there was concept of different
repositories from where the user can pull (aka install) packages.
Arch linux is, similarly to Nixos, meta-distribution - it has a tree
with the packages put in different categories and there is concept of
single user repository called AUR (Arch's User Repository).
Why that?
Well, the core system of Arch is kept in 'core' repository and the
additional packages not required for the base system (e.g Xorg) are kept
in 'extra' repo. (see
http://wiki.archlinux.org/index.php/Official_Repositories).
There are some more details here (as well as repos), but I'll skip it...
The above repos: core & extra are maintained by 'official' Arch
developers which ensures the quality/stability of the system.
However, there are many packages which do not find its place in 'core'
and 'extra' and therefore Arch has a common user-repo called AUR.
(see e.g. http://aur.archlinux.org/index.php)
Here the users can submit their packages and they become part of
'unsupported' repo. Moreover, there is concept of Trusted Users
(http://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines) or TUs
- people who are not Arch developers and cannot handle packages in
'core' or 'extra', but their job is to inspect packages submitted by
'normal' users in 'unsupported' repo and they can promote the most
popular (by vote) and/or by importance packages into 'community' repo.
One important aspect of 'community' repo is that for those packages
there are binary versions available, while those in 'unsupported' are
four source deployment.
Pretty clear isn't it?
How is this handled by package manager?
Well, official package manager (pacman) can install only 'supported
packages, i.e. those coming from {core,extra,community} set.
If the user wants to install package from 'unsupported' repo, he needs
to create a 'local' repo on his/her machine and put the package in the
appropriate place in the tree hierarchy.
The selection of repos is done in global /etc/pacman.conf, and the
interesting entries look like:
-----------------------------
[core]
# Add your preferred servers here, they will be used first
Include = /etc/pacman.d/mirrorlist
[extra]
# Add your preferred servers here, they will be used first
Include = /etc/pacman.d/mirrorlist
[community]
# Add your preferred servers here, they will be used first
Include = /etc/pacman.d/mirrorlist
# An example of a custom package repository. See the pacman manpage for
# tips on creating your own repositories.
#[custom]
#Server = file:///home/custompkgs
---------------------------------
Here is the snippet from /etc/pacman.d/mirrorlist:
# Europe
# - Austria
Server = ftp://gd.tuwien.ac.at/opsys/linux/archlinux/$repo/os/x86_64
# - Belgium
Server = ftp://ftp.belnet.be/mirror/archlinux.org/$repo/os/x86_64
# - Czech Republic
Server = ftp://ftp.sh.cvut.cz/MIRRORS/arch/$repo/os/x86_64
# - Estonia
Server = ftp://ftp.estpak.ee/pub/archlinux/$repo/os/x86_64
# - France
-----------------------------------------------------------
So, my proposal is to do something based on the above idea -
re-structure the present nixos tree into 'core' trunk, kind of 'extra'
trunk and put some not-so-important packages into kind of 'community
trunk, plus provide 'infrastructure' for NUR (Nixos User Repo) so that
new users can easily submit their nixos expressions in kind of
'unsupported' repo.
It would be nice to have something like TU in Nixos - people not
knowledgeable enough to work on 'system support', but experienced enough
to inspect nixos expressions for submitted packages and promote them
into build farm.
The ability to 'activate' repos should be handled by nix' configuration
file and nixos must be able to 'create' all-packages.nix based on the
configuration, i.e. including/excluding repos.
Of course, having some mirrors available would be bonus ;)
2) nix should handle updating of the repository tree, i.e. it should be
transparent to the user not requiring from him/her to do 'svn up'.
3) more user-friendly & configurable installer so that user can quickly
gt up in X with a working system
4) something else which I cannot remember atm...
So, please, start flaming ;)
Sincerely,
Gour
--
Gour | Zagreb, Croatia | GPG key: C6E7162D
----------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20080520/e31d49cf/attachment.bin
More information about the nix-dev
mailing list