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
libmicrohttpd dependents: fix build #105242
Conversation
Result of 2 packages built:
|
@@ -14289,7 +14289,9 @@ in | |||
|
|||
libmemcached = callPackage ../development/libraries/libmemcached { }; | |||
|
|||
libmicrohttpd = callPackage ../development/libraries/libmicrohttpd { }; | |||
libmicrohttpd_0_9_70 = callPackage ../development/libraries/libmicrohttpd/0.9.70.nix { }; | |||
libmicrohttpd_0_9_71 = callPackage ../development/libraries/libmicrohttpd/0.9.71.nix { }; |
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.
libmicrohttpd_0_9_71 = callPackage ../development/libraries/libmicrohttpd/0.9.71.nix { }; | |
libmicrohttpd_0_9_71 = callPackage ../development/libraries/libmicrohttpd/default.nix { }; |
And maybe we shouldn't use the generic file if they diverge in the future.
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.
Personally a little unclear on when to use default.nix vs generic.nix in such scenarios - most libraries where the inputs and build process remains the same seem to use generic, but there are a bunch which use default as well (usually, those have varying build inputs too)
I could live with changing it back to default if people agree that's a better fit here
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.
microhttpd doesn't see a whole lot of development - personally, I'd leave the generic derivation for now - the dependencies haven't really changed in a while.
If they do diverge, we could split it up, but I don't see a point in preemptively adding in extra things we may not need by splitting it up now
Result of 3 packages built:
|
Result of 2 packages built:
|
Result of 4 packages built:
|
Motivation for this change
microhttpd 0.9.71 introduced a breaking change that broke xmr-stak (and possibly other packages, I will be checking others)
This PR updates the libmicrohttpd derivation to allow for having multiple versions of it in nixpkgs, and updates xmr-stak, fileshare, and faustlive to use 0.9.70, prior to the breaking change.
cpp-ethereum (now known as aleth) is also broken due to this - however, it requires libjon-rpc-cpp to be fixed as well.
Additionally, aleth is now abandon ware (https://gitter.im/ethereum/aleth?at=5e7cb22c2520175199ead0ba), it may be worthwhile to consider removing it since nothing seems to depend on it, and actually running it will not get you very far.
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)