search

NixOS / nixpkgs

Nix Packages collection & NixOS
MIT License
17.58k stars 13.74k forks source link

pointing nix-build to a symlink to nixpkgs to build an isoImage fails #288170

Open evils opened 7 months ago

evils commented 7 months ago

Describe the bug

nix-build -I nixpkgs=/media/cruft/nixpkgs-link '<nixpkgs/nixos>' -A config.system.build.isoImage -I nixos-config=iso.nix results in error: The option 'system.installer.channel.enable' in '/media/cruft/nixpkgs-link/nixos/modules/installer/cd-dvd/channel.nix' is already declared in '/media/cruft/nixpkgs/nixos/modules/installer/cd-dvd/channel.nix'.

note that the two paths there are different, nixpkgs-link is a link to nixpkgs

Steps To Reproduce

Steps to reproduce the behavior:

  1. write a NixOS config (here named iso.nix)
    1. actual file used (extension changed to .txt) iso.txt
  2. clone nixpkgs into a directory (here /media/cruft/nixpkgs)
  3. create a symlink to the nixpkgs clone (here /media/cruft/nixpkgs-link)
  4. run nix-build -I nixpkgs=/media/cruft/nixpkgs-link '<nixpkgs/nixos>' -A config.system.build.isoImage -I nixos-config=iso.nix
    1. this is just how i encountered it, if there's a better minimal conflict example, please share
  5. error shown above
  6. run the same command with nixpkgs= set to the direct path and see it work

Expected behavior

nix-build to follow non-looping symlinks indefinitely

Notify maintainers

no idea who to tag here, i don't even know if this is the right repo for reporting this issue

Metadata

 - system: `"x86_64-linux"`
 - host os: `Linux 6.7.4, NixOS, 24.05 (Uakari), 24.05.git.c81209bd7a38`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.1`
 - channels(root): `"musnix, nixos"`
 - nixpkgs: `/home/evils/.nix-defexpr/channels/nixpkgs`

Add a :+1: reaction to issues you find important.

evils commented 7 months ago

236469 sounds a bit related

though the issue here isn't that it can't resolve links, but that it treats it as different before and after resolving it?

evils commented 7 months ago

i was pointed here as the source of this particular example's error

with the explanation that for some parts of this build it looks for pkgs in the parent directory relative to the given nixpkgs with .., which loses the link to the current directory while presumably something still refers to the path given in the command's argument

i suspect this could be resolved by always sanitizing inputs with the equivalent of realpath and am of course oblivious to any unintended consequences that would have :)