[Nix-dev] how does NixOS ensure focus?

[Ertugrul Söylemez]

On Mon, 28 Jul 2014 14:08:38 +0000
hasufell <hasufell at gentoo.org> wrote:

> > Whenever you install NixOS, you're really forking it, and your
> > installation becomes your own distribution.  You can then choose to
> > merge some or all changes in the official NixOS channel into yours
> > (you might call this "upgrading").  That also works the other way
> > around.  Contributing to NixOS really means that you make a change to
> > your own distribution and send a patch or pull-request.  So unlike other
> > distributions we do not actually have "contributors" or "maintainers"
> > in the traditional sense.  As far as I can tell, this model is unique.
> 
> We have a similar concept in gentoo where you can "overwrite" ebuilds
> (package definitions) by adding 3rd party repositories called overlays.
> So you can in fact mix gentoo with funtoo with sabayoon with pentoo, set
> priorities of those overlays and even force package foo from a specific
> overlay.
> However, this usually gives a lot of complicated problems where packages
> rely on certain behavior or even patches of other packages. Maybe NixOS
> doesn't have these problems due to it's technical concept, but I find it
> hard to tell at this stage.

This can happen in the form of state ("configuration") interactions.
For example it's probably a bad idea to run two versions of the same
program, when they share a state directory.  To prevent this some
programs use/allow version-specific state directories.  For example I
remember seeing directories like ~/.kde3 and ~/.kde4.  However versions
aren't the only things that affect this.  The set of available plugins
may, too.

What NixOS can do for you here is to ensure that there are no
unintended stateless interactions.  This includes libraries, programs,
stuff you would normally find in /usr/share, etc.  In other words,
there are no package-level problems.


> In addition, most user overlays have very poor quality (pretty much what
> arch linux has with AUR) and regularly break non-trivial libraries like
> SDL for example.
> 
> I see that as a big problem of decentralized packaging: quality
> assurance and consistency (consistency in a very low-level sense, as in:
> packages work with each other). From my experience it doesn't work to
> randomly review other peoples work and encourage them to more QA etc.
> There has to be a very strong attraction for people to have their work
> merged at some point.

This has to be done on the community level.  For example everything
that eventually makes it into Nixpkgs is reviewed by the committers.  I
don't think we have any formal standards here, but that may well
establish at some point.  Of course that doesn't mean that third-party
forks don't screw things up.

The current NixOS state of the art is that Nixpkgs is a safe choice and
for regular operation you don't need extra sources.  Forks are usually
used to update or add new packages, and then they are merged.  What
does happen primarily outside of the upstream Nixpkgs is experiments
and custom site-specific customisations.  This is the normal and
accepted way to do it.


> > [...]
> >
> > After half a century we have mostly figured out how to develop software
> > productively, using decentralised methods, forks, branches, merges,
> > etc.  Compared to this almost all distributions still use stone-age
> > methodologies.  NixOS is a step into the right direction, not only
> > regarding packaging, development and deployment, but also community
> > structure.
> 
> This sounds great, in a way. However, worst case scenario is that there
> are so many forks and people working on so different ideas that none of
> these can compete with up2date distributions and that getting a
> consistent experience involves a lot of research, manual fiddling and
> following unofficial tutorials and hacks.
> 
> I don't want to paint things too black, I'm just saying that it really
> depends on details and what actually happens, probably even a culture thing.

This is a theoretical possibility, but our current workflow and
community mindset makes such a scenario unlikely.  I'm pretty confident
that it will stay this way for the foreseeable future.


> But I guess I'd have to get involved in order to actually know.

You could install NixOS and pick a program that you would like to see
in Nixpkgs.  Then just add it to your local installation and send a
patch/PR to Nixpkgs, just to get a feeling of how it works, both
technically and socially.


Greets,
Ertugrul

-- 
Ertugrul Söylemez <ertesx at gmx.de>