[Nix-dev] "svn-revision" empty / nixos channel as branch?

[Vladimír Čunát]

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

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