[Nix-dev] "svn-revision" empty / nixos channel as branch?
vcunat at gmail.com
Thu Jan 24 20:08:20 CET 2013
On 01/22/2013 10:17 PM, Florian Friesdorf wrote:
> Am I correct, that the channel would be 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
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
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).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3251 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20130124/5764bc7d/attachment.bin
More information about the nix-dev