| 28 Jul 2025 |
 emily | is it the end of the world if they do? | 20:31:05 |
| emily | you could imagine having a base networkd config used on all devices to get a basic uplink but then you have some fancy stuff using ifstate. dunno :) | 20:31:20 |
| emily | like, you can also have both networkd and NM enabled, and it is fine as long as you do not try to configure the same interface with both | 20:31:43 |
 Marcel | they wonder why the changes do not apply and get overriden by ifstate, maybe even depeing on the order and between ifstate and networkd it could bing randomness demending which is faster | 20:31:49 |
| Marcel | ifstate is nice, because it deconfigures everything not defined | 20:32:07 |
| Marcel | its truly declarative | 20:32:13 |
| emily | ## ignore settings to ignore existing interface, ip addresses, … (optional)
# ignore: …
| 20:32:20 |
| emily | it looks like you can explicitly tell ifstate to ignore stuff you don't want it to manage | 20:32:28 |
| Marcel | except for the ignore part | 20:32:30 |
| emily | I think it is okay not to try and guard against everything as long as the obvious things are covered | 20:32:49 |
| Marcel | stuff like docker or libvirt managed interfaces should be there | 20:32:52 |
| emily | people can always run … some other random software that tries to tweak networking config :) | 20:32:55 |
| emily | and run into issues like that | 20:33:01 |
| emily | I would just assert on useDHCP and NetworkManager | 20:33:13 |
| Marcel | ok | 20:33:18 |
| emily | you could get fancy with config.systemd.network.{networks,netdevs,links} but I think it is not worth it | 20:33:55 |
| Marcel | but to do it corrently i also had to interpret the ignore section of ifstate | 20:34:21 |
| Marcel | * | 20:34:31 |
| emily | like | 20:36:15 |
| emily | you are also not asserting on networking.interfaces.* | 20:36:25 |
| emily | which can make scripted networking try to control things, even if useDHCP is off | 20:36:30 |
| emily | when we flip networking.useNetworkd on by default, that stuff will be backed by boot.initrd.systemd.network.enable | 20:36:32 |
| emily | but the semantics won't have changed | 20:36:33 |
 ElvishJerricco | I think it is safe to assume that if someone is enabling ifstate they are not configuring other network management tools, and therefore it's ok to only have the bare minimum of assertions to ensure that | 20:37:35 |
| 29 Jul 2025 |
| Marcel | Is there no systemd equivaltent to copy_bin_and_libs? When i use systemd.storePaths, the libs are missing. Because this is a python script it is quite annoying to specify every store path needed seperatly. | 06:49:34 |
| ElvishJerricco | In reply to @marcel:envs.net
Is there no systemd equivaltent to copy_bin_and_libs? When i use systemd.storePaths, the libs are missing. Because this is a python script it is quite annoying to specify every store path needed seperatly. I don't think we've ever tried to do Python in systemd initrd... that's indeed a new challenge. Likely the only reason it works in scripted is because it copies the whole Python program's closure, which would mean your initrd is drastically larger than necessary | 07:00:32 |
| ElvishJerricco | yea, indeed, copy_bin_and_libs ${getExe ifstate} on your branch results in a non-functional nuke-refs'd program, and using the program outside of extra-utils instead pulls in the whole closure for a whopping 75M of initrd size. | 07:22:17 |
| ElvishJerricco | * yea, indeed, copy_bin_and_libs ${getExe ifstate} on your branch results in a non-functional nuke-refs'd program, and using the program outside of extra-utils instead pulls in the whole closure for a whopping 75M increase of compressed initrd size. | 07:22:41 |
| ElvishJerricco | so getting python to behave well for initrd is going to be... tricky | 07:23:09 |
| ElvishJerricco | luckily systemd initrd gives you more control over this sort of thing, but I'm not sure what the right approach is going to be | 07:24:25 |
