Re: [aur-general] upgrade of "conf.d/*.conf"-style packages containing example configs
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
signature.asc
Description: OpenPGP digital signature
Re: [aur-general] upgrade of "conf.d/*.conf"-style packages containing example configs
‐‐‐ Original Message ‐‐‐
On May 31, 2018 10:00 PM, J. Konrad Tegtmeier-Rottach via aur-general
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.
[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
signature.asc
Description: PGP signature
Re: [aur-general] TU resignation
On Thu, May 31, 2018 at 09:03:02AM +0200, Pierre Neidhardt via aur-general wrote: > > I've stopped using Arch ever since I've switched to GuixSD[1] (a > functional-oriented distribution focusing on reproducible builds and > completely custimizable in Guile Scheme) and it's now quite clear that > there will be no coming back. > > My involvement in this new project and in others (Emacs, Next > Browser[2]) takes a lot more time than what I can afford into > maintaining my Arch packages. Thanks for your work through the years :) > - qutebrowser > - udiskie > - fzf > - pdfjs (optional for qutebrowser) > - python-keyutils (required by udiskie) > - python-pypeg2 (require by qutebrowser) I have adopted these packages! -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [aur-general] TU resignation
On 05/31/18 at 09:03am, Pierre Neidhardt via aur-general wrote: > > I've stopped using Arch ever since I've switched to GuixSD[1] (a > functional-oriented distribution focusing on reproducible builds and > completely custimizable in Guile Scheme) and it's now quite clear that > there will be no coming back. > > My involvement in this new project and in others (Emacs, Next > Browser[2]) takes a lot more time than what I can afford into > maintaining my Arch packages. > > I have a bunch of out-of-date packages in [community]: > > - emms > - qutebrowser > - udiskie > - uncrustify > > Other [community] packages: > > - catdvi > - ccrypt > - dtach > - fzf > - gtypist > - mu (A user requested that we built msg2pdf as part of the package) > - pdfjs (optional for qutebrowser) > - pstotext > - python-keyutils (required by udiskie) > - python-pypeg2 (require by qutebrowser) > - tcc > - trash-cli > - xcape > - xss-lock > > And on the AUR: > > https://aur.archlinux.org/packages/?K=Ambrevar=m > > I hope the Arch community keeps up with the good work! > > Cheers! > > [1] https://www.gnu.org/software/guix/ > [2] http://next-browser.com/ Thanks for all your work! I'll handle the disabling of your Archweb/TU account -- Jelle van der Waa signature.asc Description: PGP signature
Re: [aur-general] TU resignation
Em maio 31, 2018 4:03 Pierre Neidhardt via aur-general escreveu: I've stopped using Arch ever since I've switched to GuixSD[1] (a functional-oriented distribution focusing on reproducible builds and completely custimizable in Guile Scheme) and it's now quite clear that there will be no coming back. Hi Pierre, Thanks for your work on Arch. And good luck with this new project. - xss-lock I would adopt this, since I use it. Regards, Giancarlo Razzolini pgpvxxEmtG01Z.pgp Description: PGP signature
Re: [aur-general] TU resignation
Hi, On Thu, May 31, 2018 at 09:03:02AM +0200, Pierre Neidhardt via aur-general wrote: > - qutebrowser > - pdfjs (optional for qutebrowser) > - python-pypeg2 (require by qutebrowser) As qutebrowser's upstream, I'd be happy to maintain those in the AUR if no TU steps up to continue maintaining them in [community]. Best wishes, Pierre! Florian -- https://www.qutebrowser.org | m...@the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/ signature.asc Description: PGP signature
[aur-general] TU resignation
I've stopped using Arch ever since I've switched to GuixSD[1] (a functional-oriented distribution focusing on reproducible builds and completely custimizable in Guile Scheme) and it's now quite clear that there will be no coming back. My involvement in this new project and in others (Emacs, Next Browser[2]) takes a lot more time than what I can afford into maintaining my Arch packages. I have a bunch of out-of-date packages in [community]: - emms - qutebrowser - udiskie - uncrustify Other [community] packages: - catdvi - ccrypt - dtach - fzf - gtypist - mu (A user requested that we built msg2pdf as part of the package) - pdfjs (optional for qutebrowser) - pstotext - python-keyutils (required by udiskie) - python-pypeg2 (require by qutebrowser) - tcc - trash-cli - xcape - xss-lock And on the AUR: https://aur.archlinux.org/packages/?K=Ambrevar=m I hope the Arch community keeps up with the good work! Cheers! [1] https://www.gnu.org/software/guix/ [2] http://next-browser.com/ -- Pierre Neidhardt signature.asc Description: PGP signature
