Greetings, I'd like to derail the discussion about policy and focus on the parts about how to reduce the need to agree on policy. As others have pointed out, nix is great for having your own cake and I want to know how to make the most of it. Unfortunately, I'm incapable of really grasping nix as a language and nixpkgs in particular, so all I can do at this point is sketch some visions. As Helmut Schimidt said, people with visions should go see a doctor and given that many among you have a doctorate degree, I think this list is a valid place to turn to.
Packaging software with nix can be easy. Pick a name, point to the source, define the dependencies, done. The difficult part is that I'm not really done at this point. Ignorant of nix, I then try to find out how others have done before me and insert a line in haskell-packages.nix and maybe in all-packages.nix, too. This works out until somebody upstream adds a package with an adjacent name in the lexicographic order, that I chose to respect. Now that's a strange conflict. Intuitively, adding something to a collection should never break what's already there. Is it possible to define package names only once by placing the expression in the filesystem hierarchy? It would then be impossible to have null bytes or slashes in names but I could live with that. Having to deal with different hierarchies (attributes, filesystem, a flat namespace of names?) and naming restrictions at once is somewhat challenging, invites misconfiguration and requires more agreement. Let's talk about names. The most advanced naming system I know of is Content Centric Networking (http://www.ccnx.org/). The basic principle is that publishers assign hierarchically structured names to content and secure that binding by signing it. Consumers retrieve content by asking the network for its name and may optionally specify restrictions on what content is acceptable. For example I might ask for enumeration of names and subsequently content under ccnx:/nixos.org/pkgs/stdenv signed by Eelco and ccnx:/cryp.to/pkgs/haskell signed by Peter or ccnx:/InFactWeDon'tRelyOnDNS/home encrypted and signed by me. The protocol itself does not assign any meaning to names but there are naming conventions (http://www.ccnx.org/releases/latest/doc/technical/NameConventions.html) that are useful to follow to get versioning out of the box. It is not to be confused with a source control system as it is not concerned with merging, just with naming and getting stuff. Executive summary: Punk works best with pull semantics and preferably only one hierarchy. Cheers, michi _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
