-
-
Notifications
You must be signed in to change notification settings - Fork 14.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
btrfs-progs: build from source, not release tarball #124974
base: staging
Are you sure you want to change the base?
Conversation
If you really need to build btrfs-progs with gcc 4.8 on ARM, add this back with optionalString and substituteInPlace.
Why? |
To make it easier to override with e.g. development versions. Also makes the build more reproducible since we actually build from source and not rely on some unknown version of autotools that were run on some machine somewhere to generate the configure script for us. |
If upstream is publishing a release tarball, that presumably means they want downstreams to build from the tarball. I don't think we should deviate from that (in general, not just for this package) unless we have a good reason that applies to the package itself, not overrides people might want to do. I don't see how using configure scripts that are part of the tarball (and therefore protected against changing by the hash) could cause reproducibility issues. |
Well then we might as well fetch binaries since they're protected by a hash too. I'm not talking about the "different run, different result" type of r13y, I mean being able to reproduce the whole build, not just a part of it. Our packages should be a pure transformation from human-made source code (which is -by definition- not reproducible) to the end-result IMO. |
That'd be a departure from existing practice -- we've always preferred using release tarballs, and not having autoconf/automake dependencies unless necessary for patching. There are probably hundreds of packages in Nixpkgs that work this way. I don't think this is a change that should be made piecemeal, one package at a time, with different people making different arguments and coming to different conclusions every time. |
Result of 114 packages skipped due to time constraints:
16 packages built successfully:
1 suggestion:
|
preConfigure = '' | ||
patchShebangs autogen.sh | ||
sh autogen.sh | ||
''; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we simplify this with autoreconfHook?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about
preConfigure = '' | |
patchShebangs autogen.sh | |
sh autogen.sh | |
''; | |
preAutoreconf = '' | |
patchShebangs autogen.sh | |
''; |
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
auroreconfHook doesn't work because autoconf --force
returns this:
configure.ac:7: error: possibly undefined macro: AC_DEFINE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:246: error: possibly undefined macro: AC_MSG_WARN
Running autogen.sh is the only way to get the source to configure AFAICT.
50f367a
to
5604558
Compare
patchShebangs was redundant. |
I completely agree with @alyssais on this. If we're going to do this, it should be through a policy decision that "this is how we do it from now on". |
(Just to clarify, I do think your points are good, and we probably should
run autoconf ourselves.)
|
What would be the best way to make such a policy decision? Feels a bit small for a full RFC. A Nixpkgs issue with RFC perhaps? |
The decision should be part of NixOS/rfcs#89. |
It is larger than NixOS/rfcs#45 — which took quite some time to build at least a universally resigned attitude that nothing in it is bad enough to block. Global-impact changes are worth an RFC, small is good. And there will be scope creep to fight here, just believe me on that.
Please no. A project to collect some data for packages, and a project to shift our approach to building the packages. These do not really depend on each other, and so should not block each other or come as a bundle. GitHub is bad enough at handling large discussions to avoid mixing two discussions that can be just as easily separated. |
I marked this as stale due to inactivity. → More info |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/reconsider-reusing-upstream-tarballs/42524/19 |
Motivation for this change
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)