-
-
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
systemd depends on different derivation of systemd #98094
Comments
That's a known temporary tradeoff. See #97051 (and cross-links) EDIT: 20.09 is affected, too. |
Not only does nixos not have a split systemd.lib package, it also gets two copies of systemd in the image: NixOS/nixpkgs#97051 NixOS/nixpkgs#98094 Let's not include it for now, the only detraction is that the systemd/journald logger wont be available in uwsgi.
Not only does nixos not have a split systemd.lib package, it also gets two copies of systemd in the image: NixOS/nixpkgs#97051 NixOS/nixpkgs#98094 Let's not include it for now, the only detraction is that the systemd/journald logger wont be available in uwsgi. On the good side, the image went from 50MB to 30MB now.
Not only does nixos not have a split systemd.lib package, it also gets two copies of systemd in the image: NixOS/nixpkgs#97051 NixOS/nixpkgs#98094 Let's not include it for now, the only detraction is that the systemd/journald logger wont be available in uwsgi. On the good side, the image went from 50MB to 30MB now. The image is built against the `my-20.09` branch of nixpkgs, that is based on the release-20.09 branch with uwsgi fixes added.
This probably wouldn't be that bad if we could resurrect the separate We could probably end up patching some of the paths leading to the circular dependency to instead refer to something more mutable, maybe in |
If we can't resurrect the |
My suggestion would be to patch Thoughts @edolstra @flokli ? I know we want to keep our patch count low, as it makes maintenance a lot more streamlined (thanks for the work on that @flokli. As a result we have a lot quicker updates). But this one sounds minimally invasive (just wrap the calls around an |
We would need to trace down what's using these paths. If systemd uses that logic internally aswell, this will be a problem. The problem is not the patch length, but the necessary investigation in what's using these codepaths. |
Copying over flags from #99240. |
I personally don't have time to go through systemd source code and analyse the usages |
Note: In the old situation Introducing a This change will not require any patching of |
I don't think this should block NixOS 20.09, it's 30MB of unnecessary bloat, and I think that's it. It would be nice to have this fixed, but it doesn't need to be fixed before release. |
It's a lot more than that, e.g. 119 MiB for dbus or 85 for Emacs. We need to take closure size regressions more seriously. My system closure grows by 1-2 gigabytes per release which is not a sustainable trajectory for NixOS. And of course the situation is even worse for stuff like containers. |
Ok. Could you bring these things up not on the day of of the go/no go but when we review and merge these PRs? You're marked as one of the maintainers of this package too. The closure bloat is at best temporary. And we're very much aware of it We know how to tackle it. I just don't think postponing updates outweighs the benefits. So we made a call to merge it. Already quite a while ago. After quite a bit of discussion Happy to review any PRs that address this. I also don't understand how this PR would increase your NixOS closure. Systemd is always in the closure of NixOS. As systemd is a mandatory component of the system. This is why I thought this was the right tradeoff for now. |
NixOS is just one application of Nixpkgs, and not even necessarily the most widely used. People who use Nix outside of NixOS (e.g. for development shells or for building containers) are affected by having (multiple) systemd in the closure of everything. |
CI and build farms (like Hydra.nixos.org) are another case where you usually have different versions than your host OS or perhaps even multiple versions at once (like our different jobsets), dragging all those dependencies between remote builders, caches, etc.
One way of doing that wasn't too hard... well, Arianvp already saw the PR linked from my first comment here. (Just splitting an output wouldn't do by itself, due to eval-time cycle, at least at that time.) |
I agree that this issue matters, I just don't think it should block NixOS 20.09 release as it is mostly irrelevant to NixOS. It increases the size of an installation image, however minimal installation CD can still be burned on CD-ROM if anyone still cares about CD-ROMs. |
But NixOS 20.09 is also the stable branch of Nixpkgs for the next 6 months. So any Nix user will be affected by this issue until 21.03. (E.g. anybody running |
Again; PRs are welcome if you consider this a major blocker. Neither I or @flokli have time to work on this the coming days. This PR has been in the 20.09 branch for over a month. and was opened 2 months ago. As I said I don't see why we wouldn't backport a closure-bloat reduction PR, as already discussed in this ticket.. We won't change the major version of systemd; just change how it is packaged. Do you think that's an unacceptable solution? Why? What is the alternative solution? Revert 20.09 branch back to 243 or 245? The patches will be rather tricky to revert as unstable went through multiple systemd versions between 20.03 and 20.09 (both 245 and 246) and I think there are new nixos modules that depend on behaviour introduced in recent systemd versions. But perhaps it's worth reverting to It would be unfortunate as I know there are some people like @andir who are waiting for IPv6 fixes that landed in 246 |
It's not necessarily unacceptable but it's higher risk than we'd usually like on a stable branch. It could cause unexpected build- or runtime breakage, e.g. a package expects a file in |
Based on #99382 (comment), I don't think we should try to play cat and mouse with upstream, at least until their refactoring is still ongoing. There has been a some work ongoing recently in making our systemd expression somewhat more composable, and I propose closing this one, the current approach is somewhat safe, and much less annoying or confusing than it was while this issue was opened - and there's a clear distinction, as |
I agree this can be closed for now. We changed the derivation name so people are less confused during rebuilds. In the future we might be able to get rid of |
Describe the bug
Installing systemd pulls 2 different derivations of systemd
To Reproduce
Steps to reproduce the behavior:
1.
Investigating further, it seems that libsystemd-shared depends on cryptsetup, which depends on devmapper which depends on udev from another systemd store. it can be confirmed by going up the library chain with
ldd
andreadelf -d
5.
Additional context
Truth to be told, I'm running nixos in a podman container (
podman run -it --rm nixos/nix:latest
).Notify maintainers
@flokli @edolstra
Metadata
Please run
nix-shell -p nix-info --run "nix-info -m"
and paste the result.The text was updated successfully, but these errors were encountered: