[Nix-dev] SVN commit: nix - r25375 - in

[7c6f434c at mail.ru]

>> My point is: unless you also pass checksum or complete checkout, the build
>> will fail in chroot build (chroot build is network-isolated on purpose).
>> 
>> So you only save passing the branch in the most straightforward case.
>Not sure what this means, but I guess(hope) it's not too important.

It is somewhat important.

There are fixed-output derivations (output hash should be X or it is a 
failure. 

There are non-fixed-output derivations (output can be whatever it wants, we
only fix the build process). 

Because we want as much reproducibility as we can get, we have chroot 
builds. They can be turned on in nix.conf. A side effect of putting only 
necessary things inside chroot is that most netwok activity simply fails
(no /etc/services and no /etc/resolv.conf).

These two facts mean that if you want to override SCM revision, you also need
to specify the hash of the checkout.

>> >> Guess what gets commented on - the trivial part, or whether piece-of-art
>> >> code can be moved into "science" area?
>> >
>> >The seemingly small details still matter, because I'm trying to figure out
>> >a good approach, not just make a derivation for a single package.
>> 
>> I think that just explicit src argument and nothing else in the arguments
>> (and some meta or passthru attributes for detailed information) is enough.
>But where would the values of those meta/passthru args come from?

Constant attributes in the nix file?

>> Please take a look at pkgs/build-support/upstream-updater/ - it has a big
>> drawback of requiring 3 files per expression, but it is a working solution
>> for updating both tarball versions and fetchscm revisions to the latest
>> available. It does some things quite badly (it requires specifying data in
>> a way that is tied to specific implementation), but you can see whether it
>> does some things right.
>> 
>> I guess you could have a script that does release.nix-like walk of all
>> packages, find every package with meta.updateInfo.method defined, call
>> corresponding script to create new src expression and then (by user's
>> choice) update package src definition (I prefer to create a srcInfo with
>> some extra data like version and then just inherit needed attributes as
>> fetchsomething parameters; maybe marking srcInfo attrSet with
>> autoUpdatable = true; is a good way to mark this place for scripts?),
>> update user's personal override set (import'ed by config.nix) or discard
>> new knowledge.
>This is close to what I had in mind, although I planned to get away without 
>making lots of files. 

It is possible to avoid. You can use walker code, and you can also use 
autoUpdatable = true; 
to find the attrSet you want to override.

One problem with that approach is that if you want to update a package, you
need to find its file name; on the other hand, you can just call updater 
script on the package file by using something like
maintainers/scripts/nix-call-package