<arianvp>
so I have an idea to get rid of our nixos activation script restart systemd logic stuff
<arianvp>
and am experimenting with it
<arianvp>
so there is Unit.StopWhenUnneeded
<arianvp>
and there is Unit.Conflicts
<arianvp>
if we add StopWhenUnneeded=true for each nixos managed systemd unit
<arianvp>
and then for each generation have a target. e.g. system-1.target system-2.target
<arianvp>
and system-2.target has a Conflicts=system-1.target
<arianvp>
then simply starting the new target after activation will stop all units from the previous generation and start the units from the new one I think
<arianvp>
... wait no; because the units from previous and new generation have same names .-. darnit
<arianvp>
what if we name all units by their nixstore path? that might work
<aanderse>
arianvp: name all units by their store path? and then just alias them as real names?
<aanderse>
systemctl status blah is going to have some scary output
<aanderse>
heh
<aanderse>
well... more scary than it currently is, which brings it on par with how scary all other file names are ;-)
<andi->
NinjaTrappeur: Subject: [systemd-devel] systemd 245 released
<NinjaTrappeur>
hairpull
<andi->
I told you so on Monday :P
<NinjaTrappeur>
IK
<NinjaTrappeur>
I'm 60% through rebasing the patches on 244
<andi->
thats good, then you have a safepoint :0
<NinjaTrappeur>
I guess I'll live and breathe for systemd for the next 3 weeks at least :P
<andi->
Yeah, that is typical.
<NinjaTrappeur>
flokli did a great job and gathered some comments from a systemd dev about our patches.
<NinjaTrappeur>
We should be able to remove some of those
<NinjaTrappeur>
*after* we bump it.
<andi->
Yeah, we should do that after :)
<andi->
yeah
<andi->
and before we aren't down to 2-3 trivial patches I would advice against going to patch files...
<andi->
It makes working on rebases so much harder
<andi->
Sure it is possible but it will make it even less attractive
<NinjaTrappeur>
I disagree on that. But translating the patches I'm writing back to a git repo is kinda trivial.
<NinjaTrappeur>
So yeah, not a big deal from my perspective.
arianvp has joined #nixos-systemd
<flokli>
I think referring to our fork makes things less inspectible, and discourages people without write access to nixos/systemd to contribute. Personally, I'd prefer if the nixpkgs expression would be a bunch of patches on top of upstream systemd. This doesn't prevent anybody from massaging these patches inside a git repo, and replaying them on every version bump through git format-patch, though.
<flokli>
but that's just my opinion. If there's really a strong veto on that, fine with first getting that count down a bit. But I doubt intermediate work will happen on the nixos/systemd fork either