Conventional Commits Report

🚀 Conventional commits found.

Only a remark that it AFAICT was the purpose to always place the file to /lib/systemd/system/gvmd.service independent from any configuration option like e.g. LIBDIR according to #1662. IIRC the rationale given in the past was that it doesn't make any sense to place a systemd file to e.g. /home/matt/alts/main/lib/systemd/system/gvmd.service.

@cfi-gb I see. That explains why my cmake command has built up so many flags over the years. This seems wrong to me because:

1. I should not have to pass -DSYSTEMD_SERVICE_DIR=$INSTALL_PREFIX/lib/systemd/system to avoid permission errors when installing to my home dir.
2. Similarly, if I use root to install a second version to an arbitrary location it should not overwrite the /lib/systemd files from my main install.
3. According to the manpage it makes sense to place systemd files in /usr/local/lib/systemd/system/gvmd.service, which is not happening when I install to /usr/local.

Just to note that i'm not against this change, just wanted to mention why this might have been done like that in the past

Especially as e.g. gsad is also using the previous defaults since greenbone/gsa#3045 and changing only gvmd might be even more confusing.

OK, maybe needs a broader approach, I'll look again next week.

What may play a role for hardcoding /lib in 2021. The usr-merge wasn't covered by all major players like it is now. IIRC Debian had still a separate /lib back then and it would be the location for systemd. Other distros were earlier and for those /lib/ is only a symlink to /usr/lib/ and files shouldn't be installed into /lib anymore. Some package managers may even refuse to install such a package (contains a directory for a location which is only a symlink).
From experience as someone who dabs into maintaing recipes to create packages for package manager it is fairly normal, that specifying LIBDIR places the files relative to that position even if those are for another piece of software. The commit in question even allows to modify /etc to whatever, which may make sense or not as a location.
Imo if someone wants to manually create a systemd-nspawn container or the like, all files should be placeable where one wants to place those.

I also noticed that the same happens for another package, but I only opened it for this package to see what happens. If the reaction was positive a follow up issue would have been made. But that seems obsolete now?

Hey, my intentions with #1662 were to use sane defaults that work out of the box without adjusting any paths even when using the default prefix /usr/local. The standard setting should just work without having to set a lot of variables or to tweak system configurations. IMHO this behavior should be kept. Of course paths should be adjusted if they aren't valid anymore like if /lib/systemd is /usr/lib/systemd nowadays. I am also fine with making paths adjustable and more flexible by introducing new CMake configuration variables.

Thanks for the context @bjoernricks and @Narrat.

From what I can see, the standard settings just work, but only if you install as root, and only if you install to one place.

It's great that the standard settings are sane. Can we also have sane behaviour when I install to my home dir? For example, when INSTALL_PREFIX is $HOME/alts/main then SYSCONFDIR is being set to /etc. This to me is very poor behaviour. It will try to install somewhere that needs root, and it will overwrite any version that I've installed to /.

Maybe there's some conflict of requirements here because when installing to /usr/local the standard setting is to install to /etc. What is the reason for this? Why does a /usr/local install need to put config files like gvm/gvmd_log.conf in /etc? Does this make it easier for people following docs?

/etc is kinda special as it is the location for system-wide configuration. There is not really a different location (ignoring the oddball location /opt which can contain /opt/etc, IIRC. But /usr/local/etc is as far as I know not a thing.
But a program should not expect or need /etc. And with the rise of immutable distributions there may be further changes in the future (see for example this issue)
So in general not a problem if the configuration cannot be placed at the default location? As the program can be supplied with a path to a config?

And the difference between /usr/local/{bin,lib,(...)} and /usr/{bin,lib,(...)} stems nowadays mostly from the fact, that the latter is managed by the distribution specific package manager and no one should manually install files into that location. But /etc is kinda ignored and is "valid" for managed and unmanaged installations. With possible side-effects.
With that in mind I did look up again what locations systemd searches for unit files. And the hierarchy includes /usr/local/lib/systemd/.
https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html#System%20Unit%20Search%20Path

System Unit Search Path

/etc/systemd/system.control/*
--
/run/systemd/system.control/*
/run/systemd/transient/*
/run/systemd/generator.early/*
/etc/systemd/system/*
/etc/systemd/system.attached/*
/run/systemd/system/*
/run/systemd/system.attached/*
/run/systemd/generator/*
…
/usr/local/lib/systemd/system/*  <---
/usr/lib/systemd/system/*
/run/systemd/generator.late/*

So it isn't necessary to hardcode /lib or update it to just /usr/lib. And from the viewpoint of distributions it shouldn't potentially place files in a managed area on a manual installation.