jaeger changed the topic of #crux-devel to: CRUX (https://crux.nu/) development channel | Logs: https://libera.irclog.whitequark.org/crux-devel/
SiFuh_ has quit [Remote host closed the connection]
SiFuh_ has joined #crux-devel
pitillo has joined #crux-devel
<farkuhar> SiFuh_ thinks it would be cleaner to put the user-editable network settings in a separate file, and leave only the "business logic" in /etc/rc.d/{net,wlan,wpa_supplicant}. Even with a pkgadd.conf "UPGRADE NO" rule, and a handbook section explicitly endorsing the in-place editing of those rc-scripts, some users still feel uncomfortable editing files that aren't purely declarative.
<farkuhar> "separate data from code" is the relevant principle here.
<SiFuh_> Well, it does deserve a discussion
<farkuhar> For users who do feel comfortable editing the scripts directly, it's very convenient to see the variables declared right above the code that uses them. It's more awkward to open two separate editor buffers, to obtain a complete picture of how the services are started.
<farkuhar> The default pkgadd.conf already exempts the net and wlan scripts from being upgraded, but the wlan script doesn't actually define any variables that the user might want to edit. The more appropriate pkgadd.conf rule is arguably "UPGRADE ^etc/rc\.d/wpa_supplicant$ NO", since the user-editable fields are all in wpa_supplicant now.
<farkuhar> But if we implemented SiFuh_s suggestion and separated the data from the code, then the default pkgadd.conf would have to be rewritten accordingly.
<SiFuh_> farkuhar: What if the entry was added to rc.conf for Wi-FI, net, DHCP, Static IP addresses and also move the colour option into rc.conf but more simplified?
<farkuhar> Putting into rc.conf everything that the user might want to edit? That might make the configuration more streamlined, at the risk of overwhelming the typical CRUX newbie.
<SiFuh_> farkuhar: Why? Editing one file instead of 3?
<SiFuh_> farkuhar: in BSD we usually edit rc.conf for all rc scripts. OpenBSD has rc.conf.local though for modifications that the system administrator does and it overrides rc.conf
<farkuhar> Now if all the user-modifiable variables and functions were sequestered in rc.conf, then you could delete from pkgadd.conf the two lines referring to /etc/rc.d/{net,wlan} , allowing us to ship new versions of those scripts (without a "notify: use rejmerge" announcement) if the API ever changes (ifconfig replaced by ip, for example).
<SiFuh_> As for the functions, that was just a suggestion. rc.colors would probably make more sense. But it depends how compact the colour line could be if used in rc.conf.
<farkuhar> jaeger said it was possible to achieve the current functionality by defining BOLD, RED, and GREEN as shell variables, not functions. So in principle you could have those be one-liners in rc.conf.
<SiFuh_> farkuhar: even with a comment stating an array so colours could be COLOUR="green white blue"
<farkuhar> As for whether you'd want the user to have full control over variables that are passed to printf as the format string, that's another issue. With printf interpreting the control characters, you run the risk that a user might render their terminal unreadable by defining BOLD RED or GREEN as an inappropriate control code.
<SiFuh_> Yeah, that needs to be rewritten correctly.
<SiFuh_> farkuhar: Well you could put in checks so if a variable in the array was wrong or blank, it would revert back.
<farkuhar> In any case, OpenBSD is a useful example to follow, because it demonstrates how all the configuration can be centralized in a single file.
<SiFuh_> farkuhar: FreeBSD does it too. Not sure about NetBSD though.
<SiFuh_> farkuhar: If CRUX boasts about BSD style init scripts, it would kind of make sense to follow it though.
<cruxbridge> <js> /etc/rc.conf on NetBSD
<SiFuh_> THanks js