[aur-general] upgrade of "conf.d/*.conf"-style packages containing example configs
Hi, I've run into a general issue with software packages that use a configuration directory, aggregate configs therein using a glob rule on the filenames, and contain an example config. An example is `community/consul`, which - globs for `/etc/consul.d/*.{hcl,json}` - contains `/etc/consul.d/example.json` When I configure these types of software first I delete the example file, and then place additional configs in that directory, with everything working as expected. Then an upgrade for that package rolls around, and the example config is recreated. This usually means that as soon as the software reloads, the recreated example config gets loaded, too, and the software tends to fail or behave in byzantine ways. After consulting the wiki about this [0], I had assumed that this is the "original = X, current = Y, new = X" case and the example config shouldn't be recreated, but it seems deletion isn't handled the same as modification here. (.pacnew files aren't an issue since the glob rule is in place) What is the proper way to deal with these example configs? Truncate them to force the XYX upgrade case, which seems hacky? Set `NoUpgrade` [1] in the PKGBUILD, assuming this is applicable here? I ask this here because my `aur/nomad-bin` package has this exact problem. Regards, KT [0] https://wiki.archlinux.org/index.php/Pacman/Pacnew_and_Pacsave#.pacnew [1] https://wiki.archlinux.org/index.php/Pacman#Skip_file_from_being_upgraded
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On May 31, 2018 10:00 PM, J. Konrad Tegtmeier-Rottach via aur-general <aur-general@archlinux.org> wrote:
Hi, I've run into a general issue with software packages that use a configuration directory, aggregate configs therein using a glob rule on the filenames, and contain an example config. An example is `community/consul`, which
- globs for `/etc/consul.d/*.{hcl,json}` - contains `/etc/consul.d/example.json`
When I configure these types of software first I delete the example file, and then place additional configs in that directory, with everything working as expected. Then an upgrade for that package rolls around, and the example config is recreated. This usually means that as soon as the software reloads, the recreated example config gets loaded, too, and the software tends to fail or behave in byzantine ways.
As a rule of thumb, if a software package ships an example config, it should IMO not be made effective on installation, unless it's "generally applicable or useful" in that it then needs only minor edits for each particular use case. You can see how this definition on its own makes room for interpretation already, though. My guess is that a package that breaks due to re-shipping its own example configuration qualifies for a bug. Many software packages (systemd is taking the cake today) ship their example configuration somewhere in /usr, which seems a better idea, because there they don't accidentally become effective. Oftentimes these problems occur due to ignorant or uninformed upstream which would benefit from people like you who are reporting these problems. That said, are you interested in finding more of these packages? I can think of a wonderful role for you around here. cheers! mar77i Sent with ProtonMail Secure Email.
Le 31/05/2018 à 22:00, J. Konrad Tegtmeier-Rottach via aur-general a écrit :
Hi,
I've run into a general issue with software packages that use a configuration directory, aggregate configs therein using a glob rule on the filenames, and contain an example config.
An example is `community/consul`, which - globs for `/etc/consul.d/*.{hcl,json}` - contains `/etc/consul.d/example.json`
When I configure these types of software first I delete the example file, and then place additional configs in that directory, with everything working as expected.
Then an upgrade for that package rolls around, and the example config is recreated. This usually means that as soon as the software reloads, the recreated example config gets loaded, too, and the software tends to fail or behave in byzantine ways.
After consulting the wiki about this [0], I had assumed that this is the "original = X, current = Y, new = X" case and the example config shouldn't be recreated, but it seems deletion isn't handled the same as modification here. (.pacnew files aren't an issue since the glob rule is in place)
What is the proper way to deal with these example configs? Truncate them to force the XYX upgrade case, which seems hacky? Set `NoUpgrade` [1] in the PKGBUILD, assuming this is applicable here?
Whether a deleted file should count as a modified one for this regard, I don’t know but I would say so. Will leave that to pacman devs. However, as a workaround you should rather use NoExtract than NoUpgrade. Unless you actually want to see the new example file of course. Regards, Bruno
participants (3)
-
Bruno Pagani
-
J. Konrad Tegtmeier-Rottach
-
mar77i＠protonmail.ch