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 ----------------------------------------------------------------
pgpOPOi5c69dT.pgp
Description: PGP signature
_______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
