Hello again, Fear we're sliding off-topic here, but will try to follow up anyway in case my input is in any way helpful.
On Tue, Jul 04, 2023 at 12:08:36PM +0200, Francesco P. Lovergine wrote: > First of all, sorry for the use of irritual instead of weird (false friend > term applies > in this case, for non native speakers). I'm not a native speaker myself. > > About the discouraging of EnvironmentFile could you please point where > it is expressed in the Policy? By Policy I assume you mean Debian Policy? My most recent interaction with policy was to to remove policys very detailed description of how sysvinit worked which was forbidding things like startpar and insserv, which has been mandatory for decades in Debian under sysvinit. By then there wasn't a single mention of systemd. Maybe things have changed in the last couple of years, but I would definitely not take Debian Policy as a authoritative source for any systemd related recommendations. > For sure, Debian has impressive use of the /etc/default/ tree > which was and still is Debian specific. The /etc/default pattern is for sure both Debian and sysvinit specific. The same thing exists as /etc/sysconfig in RH/RPM world. I guess unifying this was never useful since init scripts where always very distro specific anyway. Notably /etc/default/foo is posix shell, while EnvironmentFile= takes a key=value file (without executing it in shell context). This means that for example if /etc/default/foo contains: ``` UNAME="`uname -a`" ``` You would get different results with the init script pattern vs systemd EnvironmentFile=. > That is probably the origin of those rumors. > > Indeed, enabling/disabling of services by using an option in /etc/default/ > (as for a lots > of services in the past) is considered a bad practice due to the old init > sysv days. Today, one should enable/disable the unit instead, which is much > more clean. That make sense. Now you are talking about the infamous NOSTART anti-pattern, which is a different problem and should for sure not be used (unrelated ot which init is used). > I disagree with a general deprecation > of Environment entries instead (files or vars), which is optimal mode of > solving > configuration issues without writing whole units or overrides. But on those > regards, > using a non-templated unit as a pseudo-templated is a very strange choice. > > Anyway it is your choice. For sure not my choice. I'm just providing something in the hope that things will move forward as they seem to have been stagnant for this package up until this day. Regards, Andreas Henriksson
