[Nix-dev] On nixpkgs and reasonable code size

[Vladimír Čunát]

On 02/21/2016 03:17 PM, zimbatm wrote:
> tl,td; I think that we should split nixpkgs/pkgs in two

OK, let's discuss.
TL;DR: I quite don't get where to draw the line, and what the
relationship of the two sets would be.

> nixpkgs is getting pretty huge. There is so much surface, [...]
> 
> We have a list of officially-supported packages (the ones built by
> hydra). As a user, when installing a package it's not always clear if
> the package is supported or not.
> As a nixpkgs maintainer it is also unclear what priority should be given
> to each package as the of officially-supported packages is not first
> class. For example gettext is used everywhere but not directly part of
> release.nix

I think most packages actually are built on Hydra, and we encourage new
ones to set meta.platforms, as otherwise the state tends to rot. (Of
course, only a limited set of configurations and platforms is built.)

Importance of a package seems a rather subjective matter. Still, it
shouldn't be hard to distinguish a set of packages that happen to be
present in a large fraction of build-time closures. (That's close to
"the" set of mass-rebuild packages with some additional ones, e.g.
xorg-server.)

Assuming we did decide on what package to put where, what then? Do you
mean that support for the less important part would be allowed to lag
behind? E.g. heavy-impact changes would only be well-tested on the more
important part before merging, and the community might take care of the
rest later without blocking channels etc.?

--Vladimir


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3771 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160221/bdc22d60/attachment.bin