On 01/22/2013 10:17 PM, Florian Friesdorf wrote:
Am I correct, that the channel would be trunk-combined? http://hydra.nixos.org/jobset/nixos/trunk-combined
That depends on your use case. I have only services in nixos and so I rebuild it very rarely. However, I quite often build or update something from nixpkgs. That's why I only used the nixpkgs, moreover the additional things in nixos IMHO aren't usually very build-time intensive.
nixpkgs is independent of nixos, nixos needs nixpkgs. % du -sh dev/nixos/nixos 17M dev/nixos/nixos % du -sh dev/nixos/nixpkgs 152M dev/nixos/nixpkgs I think the size at least is not an argument for separate repositories.
Yes, I see this the same way.
Having separate repositories, it would be great to register the revision of nixpkgs being used for nixos. Registering nixpkgs as a submodule for nixos would achieve exactly that. However, there would be quite some commits just for upgrading the submodule - I'm not sure how useful that is.
The main dependency I see is when the service-package gets updated in synchronously one needs to update the nixos service definition. These two changes should IMHO be somehow seen as interdependent, probably in one commit, but there may be other solutions.
On the other hand for hydra to publish what versions have been successfully built together is definitely useful, but she does that already.
Yes, and one can often judge from the time stamps... now when rebuilding nixos I always fetch both repos at once to minimize these risks (so I don't see this as a critical problem, just a minor enhancement).
The hydra channel could be a git repository with two submodules (nixpkgs, nixos) and hydra updates these in the "master" branch for every attempted combined build. For every successful combined build it moves the "tested" branch forward.
That could be a nicer way to automatically find out which versions were built together (although we already have it now, in a less efficient way).
Vlada
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
