linuxManualConfig: revert #221707

[ghost]

Description of changes

This PR reverts #221707, which broke: kernel builds on all flavors of PowerPC, kernel builds on all flavors of MIPS, the isModular parameter, and the buildDTBs parameter.

That PR caused our linuxManualConfig expression to perform its builds from source code unpacked into /nix/store rather than unpacked in $NIX_BUILD_TOP like the standard builder and nearly all other packages do. I believe this was an unwise decision: it generally isn't safe to assume that software won't write the path to parts of its source code into its binaries. Strippable debug symbols are only one specific case of this problem; there are plenty of others. This is why the nixpkgs standard builder builds in a temporary directory (and why the sandbox ensures that the name of that directory is exactly the same for every build). All modern distros use sandboxes (in part) to solve this reproducibility obstacle.

Unfortunately #221707 was followed very quickly (two weeks) by #222426, which moved an enormous chunk of code from one file to another. Because of this, it's impossible to cleanly revert anything earlier than that. Therefore, I have unfortunately had to revert all changes to pkgs/os-specific/linux/kernel/{manual-config,generic}.nix since #221707. Fortunately at this point most of them are either treewides or attempts to deal with the fallout of #221707. I don't know how much longer that will be the case, which is why I wanted to open this PR while it's still possible.

I contacted @alyssais on IRC to ask if she had plans to address the breakage. She said that she is taking some time off from Nixpkgs. In light of that I think it's best if she resubmits these changes when she has more time to discuss and analyze their impact.

Please don't squash the history; it's important to be able to see how I created this commit series. After this PR merges I will try to cherry-pick as many of the changes as I can, but I'd like this to be a clean rollback to a known-good state so that if any of my cherry-pick attempts cause breakage they can be reverted independently of this PR.

Closes #240765
Closes #224694
Closes #244438
Closes #225756

Things done

• Built
  • pkgsCross.powernv.linux on x86_64-linux
  • pkgsCross.mips64el-linux-gnuabi64.linux on x86_64-linux

[ghost]

@ofborg build pkgsCross.powernv.linux

[ghost]

pkgsCross.powernv.linux on x86_64-linux — Success Details

[alyssais]

I contacted @alyssais on IRC to ask if she had plans to address the breakage. She said that she is taking some time off from Nixpkgs. In light of that I think it's best if she resubmits these changes when she has more time to discuss and analyze their impact.

👍

[ghost]

Rebased.

This PR is likely to experience more annoying merge conflicts, so I intend to merge it as soon as ofborg signs off.

[ghost]

Okay, I opened four PRs to reapply the easy changes.

The remaining are:

• 41f788b "linuxManualConfig: use the default make target" which is a good idea but was implemented in a way that caused buildDTBs and isModular to be ineffective
• febe477 "linux: default stdenv.hostPlatform.linux-kernel" -- also probably a good idea but needs to be done very carefully
• f521f46 "linuxManualConfig: get rid of drvAttrs" -- the commit that moved a big chunk of code from one file to another; it's a good idea but we should wait until things settle down and we're sure nothing will need to be reverted before doing this.
• 7de3f08 "linuxManualConfig: unpack directly into $dev", which I'm not sure ought to be reapplied
• d57568f "linuxManualConfig: install GDB scripts" -- this probably needs to be done differently if it is to be used without the previous commit.

It appears that a695425 isn't necessary; I think it was a partial revert of something that hasn't yet been unreverted post-this-PR.

[PedroHLC]

@amjoseph-nixpkgs since you're at it (linuxManualConfig), is there anything blocking us from getting rid of allowImportFromDerivation all-at-once by copying configfile during preparePhase after make defconfig and then converting all the extraConfig to arguments for scripts/config (and running git)? This way we would never have issues with import-from-derivation and we could mix configfile with extraConfig without headaches.

[ghost]

is there anything blocking us from getting rid of allowImportFromDerivation all-at-once by copying configfile

Settings from user-provided .config files would then not be reflected in .passthru.config, which might change the behavior of other packages that inspect that property.

So we would need to drop .passthru.config first and see what breaks.

IFD is only forbidden in nixpkgs proper; nothing in nixpkgs uses it except linux-kernels.customPackage, which is for use by code outside nixpkgs. So I don't really see an issue here. Also since uses of this come from out-of-tree we can't really see what we're breaking here. This is probably really convenient for people with goofy hardware where they just want to cat /proc/config.gz from a vendor-supplied kernel image in order to switch to a nixpkgs-built kernel.

[PedroHLC]

Thanks, your answer was much better than I could have expected.