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
Remove uses of libOnly #39683
Remove uses of libOnly #39683
Conversation
31045c8
to
8cc82a6
Compare
It looks like libkrb5 is still needed for bootstrapping.
8cc82a6
to
12c528d
Compare
Overrides should only be on the "default" package not the other way around.
3a02b6b
to
db7356c
Compare
Failure on aarch64-linux (full log) Attempted: krb5, libkrb5, pulseaudio Partial log (click to expand)
|
Failure on x86_64-darwin (full log) Attempted: krb5, libkrb5, pulseaudio Partial log (click to expand)
|
Failure on x86_64-linux (full log) Attempted: krb5, libkrb5, pulseaudio Partial log (click to expand)
|
01f492e
to
b92e221
Compare
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.
Excellent! Hopefully after these no-brainer split-outs we can get back to tackling the original problem.
@Ericson2314 It looks like we are getting infinite recursion with krb5 (curl depends on it, so anything using fetchurl needs it). I wonder if this is a case where we really need "libOnly"? There are a few similar "bootstrapping" derivations that are needed for similar reasons like:
It would be nice to hide these so people don't accidentally use them directly. Not sure if that is possible though. |
b92e221
to
a7a6c2d
Compare
ugh this bootstrapping stuff is no fun. These days I'm not sure why we don't use the corepkg fetchurl more. When we redo bootstrapping to use the cross stuff, we can finally get rid of these derivations. Making them |
Something similar is being done in #38494, might want to coordinate to avoid duplicate work. |
Well, thinking some more about this, I'm now unsure removing all of `libOnly` is a good idea anyway. I agree it shouldn't be overused, but `libOnly` is useful, not only for bootstrapping.
E.g. in case of `pulseaudio` and `jack`, those are pretty big pieces of software, but their libraries are pretty small, so, until we build against `libcardiacarrest` and (yet non-existent) `libemptynest` (or whatever) by default, having `libOnly` makes sense. It shouldn't be set by default, when possible, for hydra builds, I agree, but it would be nice to keep the option for independent builders (like me) that could then override things they don't need binaries for with `libOnly`.
(Actually, now what I think about it, it would be cool to have a maintained library of standard override profiles, like "everything minimal", "everything full", "suckless only", etc.)
What I think is totally reasonable part of motivation behind this PR is a homogeneous derivations for both values of `libOnly`. I.e. enabling `libOnly` should only produce `lib` (and `dev`, etc) outputs, and disabling would produce all of them.
In short: I think we should keep `libOnly`, but set it to `false` by default, and make derivation outputs homogeneous.
|
Closing because #38494 is further along. |
Oops, I got carried away and forgot that `Only` in `libOnly` means something different from my memory model, hence I should've used different terms.
What I wanted to say is I want derivations to become monoids. So, I think, `libOnly` should be split into `withBinaries` and `withLib` (or similar), because both are useful. (The rest of the previous comment is ok.)
Then, we can continue from the parent issue on the usage of `.override`s in derivation themselves for specifying features they expect from dependencies. Clearly, derivations with use-flags are monoids (`libOnly` is not a use-flag, while `withLib` and `withBinaries` are).
Hence, when nixpkgs finally implements use-flags we could make packages specify expected features of their dependencies and export that information, and then merge all those requests using `bool any` (see discussion in #37252) monoid (or something more interesting, if we want use-_options_ instead of use-_flags_) and build `pkgs` using that.
E.g., you gather all "use-flag requests" from packages in `systemPackages`, build use-flag specification, supply it to `pkgs`, now you have the perfect package set. Merge some "hydra-use-flags" into there, and now you only rebuild things that hydra didn't build.
Note that the gathering part is exactly isomorphic to `options + config` of NixOS modules, while the rest is exactly isomorphic to monoidal services (see the "Service composition" thread from 2014-12-26 on nix-dev ML by @esoeylemez and #35900).
|
We failed to get any sort of consensus on #39515 so I am opening this spinoff PR that focuses on the worst overrides offenders. Basically, a few packages rely on this legacy "libOnly" flag that tells them to only build the "library" part of the package.
What's wrong with libOnly
libOnly is an attempt to be more precise on what a package builds. The goal is to decrease closure size. Unfortunately, it's usage also means that you have to build each package twice - once for the libraries and another for the actual runtime (even though the runtime will still build the library). Since multiple outputs have been released, this is no longer the correct way to decrease closure size. Outputs like "lib" and "dev" should be used instead and mean you only have to build things once.
Current offenders
Backwards compatibility
This PR retains aliases for each of the libOnly overrides so old references to "libpulseaudio", and "libjack", etc. will continue to work.