[Nix-dev] substitute hell ?

[Sergey Mironov]

Ok, here is the real cause of my situation. Long time ago, someone
added libass package. He defined it's arguments and one of them was  {
... , enca ? null }. But there was no enca package in the tree so null
was used. Yesterday I was trying to build my tree with several new
packages and one of them was .. guess what :)  enca. So this pure
little enca becomes a bomb in my case. Of cause it broke the
substitution for libass and for all packages depending on it... Ok,
well. No magic, no mysteries. Git mirror works just fine.

But really, I want a tool explaining the user why does nix can't use a
substitution!


2012/6/3 Sergey Mironov <ierton at gmail.com>:
> Crap, looks like I've found it. Nixos/nixpkgs trees I used recently
> were obtained from git mirror. I tried to update using a tree directly
> from svn (of corresponding revision) - and it worked! nix successfully
> installed vlc using substitution. vlc expressions are the same in both
> trees. If I understand correctly, that means that they have different
> derivations for some reason, svn is lucky and produces a correct one.
> But damn, now nixos-rebuild doesn't want to write a path to this
> derivation for me, and I can't compare it with the one of git-tree.
> oh, tired of mysteries..
>
> Anyway, thanks..
>
>
> 2012/6/3 Sergey Mironov <ierton at gmail.com>:
>> Thanks for quick answer
>>
>>
>>
>> 2012/6/3 Eelco Dolstra <eelco.dolstra at logicblox.com>:
>>> Hi,
>>>
>>> On 02/06/12 16:25, Sergey Mironov wrote:
>>>
>>>> We know that vlc package depends on a52dec. We have a substitution for vlc:
>>>>
>>>> $ sudo nix-env -qas  'vlc' --system --out-path
>>>> --S  vlc-2.0.1  x86_64-linux
>>>> /nix/store/x332qx57qbak8rbmg4hhbjr5m7afn2df-vlc-2.0.1
>>>> --S  vlc-2.0.1  i686-linux
>>>> /nix/store/vwvz7hh1yc1bvjn6avylbzlgib8d2b60-vlc-2.0.1
>>>> --S  vlc-2.0.1  i686-linux
>>>> /nix/store/vwvz7hh1yc1bvjn6avylbzlgib8d2b60-vlc-2.0.1
>>>> (hm.. why are there two of them. ok, let it be so)
>>>
>>> I only have one.  Maybe you have multiple channels (e.g. nixos-unstable and
>>> nixpkgs-unstable)?  If you want to find out where they're coming from, use the
>>> -P flag to see the corresponding attribute name.
>>
>> O, thanks, with -P flag it says
>>
>> $ sudo nix-env -qas  'vlc' --system --out-path -P
>> --S  latest.0        vlc-2.0.1  x86_64-linux
>> /nix/store/x332qx57qbak8rbmg4hhbjr5m7afn2df-vlc-2.0.1
>> --S  latest.1        vlc-2.0.1  i686-linux
>> /nix/store/vwvz7hh1yc1bvjn6avylbzlgib8d2b60-vlc-2.0.1
>> --S  nixos.pkgs.vlc  vlc-2.0.1  i686-linux
>> /nix/store/vwvz7hh1yc1bvjn6avylbzlgib8d2b60-vlc-2.0.1
>>
>> where "latest" is the name of vlc's channel I've added, but then
>> removed (!). Currently, my user's ~/.nix-channel is empty and root's
>> ~/.nix-channel contains only reference to nixos-latest. Probably there
>> is another cache elsewhere, maybe nix-env has one? (oh, I've found the
>> place: ~/.nix-defexp/channels/latest -> vlc's manifest. May it be a
>> result of unlucky Ctrl+C ?) Anyway,  probably It is not a major
>> problem.
>>
>>>> Threre is no substitute for a52dec! (And for some reason I can't find
>>>> a52dec job on a hydra website). How did hydra compile vlc without
>>>> building a52dec? If it actually did compile a52dec, then what is wrong
>>>> with it's substitution?
>>>
>>> This is because a52dec is only a build-time dependency and not a runtime
>>> dependency.  (This might suggest that vlc doesn't actually do anything with
>>> a52dec, in which case it should be removed as a dependency...)  So Hydra does
>>> build it, but it doesn't end up in the channel because the channel only contains
>>> runtime dependencies.
>>>
>>> (In the past the Nixpkgs channel also contained build-time dependencies.)
>>>
>>
>> The actual reason I started investigation is the behavior of
>> nixos-rebuild. It wants to build  derivations for vlc and a52dec
>> locally. By the way, a52dec is plainly listed in vlc's buildInputs.
>> How can nix determine that it is a built-time dep without building vlc
>> and scanning it's binary?
>>
>> In general, Is it possible to ask nix, why does it want to build a52dec?
>>
>> [~/proj/nix] $ sudo nixos-rebuild -I . dry-run
>> building Nix...
>> building the system configuration...
>> these derivations will be built:
>>  /nix/store/7g09vsdbp72zhbd0pkada0klynmax153-etc.drv
>>  /nix/store/8ha1qnpy6havqb468xzzhy3nr6gr47xl-upstart-xserver.conf.drv
>>  /nix/store/9zqw7kri0n7i138rzv25dc0zqa3fcqyy-nixos-0.1pre-svn.drv
>>  /nix/store/h2y1c5gaa5x1h34qx3jyf42n8knkzjwb-system-crontab.drv
>>  /nix/store/lvghnv1ifyx3jw10icvy2nvf4hmj5z2z-system-path.drv
>>  /nix/store/n2fwa36yjl0acrvglhh79mb615g84h44-slim.cfg.drv
>>  /nix/store/pnwplhaa56nqjshsy9karl692kdigdwz-vlc-2.0.1.drv
>>  /nix/store/x90bxbllmwz41q7mvs5lbiy3apxab900-dbus-conf.drv
>>  /nix/store/xjcp6j81yjclkrsndk0kn459mpm8sygq-xsession.drv
>> (a52dec is already locally compiled and doesn't mentioned here)
>>
>> PS
>> My custom dev tree is basically a current svn-head + some new
>> packages. All packages are installed via nixos-config, nix-env -q '*'
>> is empty for all users.