<arianvp>
flokli: yeh I think patching path-util.h should be enough
<arianvp>
im confused htough
<arianvp>
the commit msg says: @rootbindir@ is always in
<arianvp>
our internal $PATH that we use for non-absolute paths, so there should be no
<arianvp>
functional change.
<arianvp>
so things hsould not be broken, given we set up @rootbindir@ correctly?
<andi->
as long as we have systemd's bin dir in PATH for all systemd processes that should be fine... I wonder how upgrades will look like..
<andi->
I hope it re-execs before restarting services
<flokli>
andi-: the problem with that latest iteration is that ${placeholder "old"} is a placeholder for the substituteAll, not for systemd
<flokli>
I'm not sure if it's even possible to add the systemd stuff into there - without manually sed-ing the patch in prePatch.
<flokli>
we probably can't just point to /run/current-system/systemd, as that might not always be correct during activation of a new system, right?
<andi->
We are setting up paths before doing anything system. The activation scripts run before systemd is exec'ed. The interesting parts are a) systemd upgrade (re-exec and if the new binaries are there before/after re-exec) b) rollbacks
<NinjaTrappeur>
also, I'm definitely in favor of keeping the git repo for now.
<NinjaTrappeur>
I fear the patch-based workflow will make us miss some newly introduced fhs paths previously fixed by the patchs.
<NinjaTrappeur>
But again, the translation patch <=> git repo is pretty straightforward, so let's not bikeshed that too much :D (this includes me evoking this again ><)
<flokli>
NinjaTrappeur: we can keep the git repo to manage patches, but dump them into nixpkgs trough format-patch ;-
<flokli>
For both workflows, you need to look if the patch still applies semantically too.
<flokli>
maybe we can use something like git-series to help managing these patches, but I consider the history of our stack of patches (and how and why we minimize them) important…
<andi->
NinjaTrappeur: do you have a matching nixpkgs fork that I can use to test this on Hydra?
<flokli>
andi-: I updated mine, and got the systemd-networkd test to pass on systemd 245
<flokli>
triggered a evaluation on hydra :-)
<flokli>
NinjaTrappeur's systemd fork still contains a lot of back and forth. Maybe even if you still don't want to have these patches in nixpkgs in the end, we might want to have our patchset look like more like that
<flokli>
(and somehow document how we got there)
<flokli>
I still think keeping the evolution of that patchset in nixpkgs is the right way to make this understandable and acessible.