<arianvp>
worldofpeace: just give me a ping if we need to invoke the nuclear option
<arianvp>
(that is; roll back to v245)
<arianvp>
I suggest only partially reverting it. We had to replace many calls of `systemd.lib` to `lib.getLib systemd` but I wouldnt want to revert all that
<arianvp>
because it would mean reverting hundreds of packages; and the behaviour should be the same (if there is a split library output, it will use it)
<NinjaTrappeur>
arianvp: I think patching temporarily the now private interface would be preferable.
<NinjaTrappeur>
As a worst-case scenario approach.
<andi->
So, I looked a bit into the systemd situations. The biggest problem is probably that meson doesn't have the concept of runtime vs install paths. I've started hacking on a PoC that would make it work for NixOS. The bianries will carry references to /run/… while the installation still happens to the "vanilla" paths.
<arianvp>
andi-: yeh I think that would be a clean solution, I was working on a similar patch but mine is alot more ad hoc
<andi->
mine is really ad-hoc right now. I think that would work for us with reasonable effort to keep up2date (as builds fail if we missed something).
<andi->
Unfortunately meson doesn't set any standards on how to do packaging so they really just invested their own stuff there (as far as I can tell)
<arianvp>
yep
<arianvp>
my idea was to have all the #define's that meson sets refer to /run
<andi->
that is what I just did
<andi->
and it did build and I am running the tests now
<arianvp>
whilst the directives they use in the meson.build refer to the $out path
<arianvp>
ah perfect
<arianvp>
good that we had the same idea =)
<andi->
but now I'm building qemu and gtk and sdl and … so I'm taking a detour into #49403 again
<andi->
One last thought: was does it take to remove the duplicate systemd build? What did we gain by doing that?
<arianvp>
we gained cryptsetup support in systemd
<arianvp>
lvm2 depends on udev (because it talks to libudev; though that can be optionally disabled in the build; haven't tried), but systemd pulls in lvm2 when cryptsetup support is enabled
<arianvp>
iirc
<arianvp>
that was the cycle
<arianvp>
one solution would be to build libudev in a separate derivation; or have a systemdMinimal with most features disabled
<arianvp>
both are the same solution; just libudenv is a _super minimal_ systemd :P
<damjan>
btw, is it suggested to use `getLib systemd` now?
<damjan>
and how about `lib.getDev systemd`?
<arianvp>
usign getLib and friends is usually the right call in generic code; where you are not sure whether the code has multiple outputs or not
<arianvp>
since systemd doesn't have a lib output atm; but might again in the future; we opted to change all the systemd.lib calls to getLib systemd so we dont need a large patch later on
<arianvp>
idk if we might want to revert that or not; andi- thoughts?
<damjan>
I have a patch for pkgs/servers/uwsgi/default.nix to add `lib.optional withSystemd (lib.getLib systemd)`
<arianvp>
for now that is the right call. as systemd.lib doesnt exist at the moment
<arianvp>
(due to a temporary snafu)
<damjan>
yeah, read the discussions
<damjan>
I've read*
Mic92 has quit [Quit: WeeChat 2.9]
Mic92 has joined #nixos-systemd
<arianvp>
I never understood this "withX" pattern
<arianvp>
why not just pass in "package = null" if you want to not build a package?
<arianvp>
or does that not work
<arianvp>
its very widespread in nixpkgs so I might be missing something
<damjan>
hm
<damjan>
I'm a complete newbie about that
<arianvp>
me too :D
<arianvp>
but some others here ar not; so I hope they perhaps know
<arianvp>
NinjaTrappeur: why does making a dbus method hidden break things though?
<arianvp>
eventhough it's hidden, it should still be callable no?
<arianvp>
(I must say I haven't followed the KDE discussion closely; but the commit that was linked doesnt seem to make a breaking change to me on first sight)