control: retitle -1 nano: please support general configsnippet.d/* mechanism control: severity -1 wishlist
Quoting Benno Schulenberg (2020-02-03 14:23:38) > > Op 02-02-2020 om 14:14 schreef Jonas Smedegaard: > > in Debian I would argue that it makes sense for the default shipped > > master configfile to include 'include "/etc/nano/*.nanorc"' (and > > also ship an empty dir/file as needed if nano chokes on a include > > directive pointing to a missing dir/file). Reason being that there > > are arguably not one but two "machine admins" below /etc on Debian > > systems: Debian and the sysadmin. It makes sense for the sysadmin > > to be able to tinker with config snippets without tampering with the > > master config file, so that if the master config file later needs > > updating by the package, that can happen automatically without > > consulting the sysadmin how to deal with a locally forked changed > > file. > > I see. However, the files in include statements can only contain > color syntaxes, not any option settings. Oh! I missed that "minor detail" which changes this issue from a "please package a slightly different configfile in Debian" to an upstream issue of "please support a mechanism for including general config snippets (not only styling snippets)". > And in my opinion the machine admin should not "burden" the user with > extra syntaxes, because the admin is unlikely to know which syntaxes > the users want and need. On the one hand it is nice that Debian does > an 'include /usr/share/nano/*.nanorc' in nano's main config file, so > that some files have syntax coloring by default. But on the other > hand this unnecessarily burdens and slows nano down for users that > don't need any coloring, or want it only for a few specific file > types. > > It would have been better if Debian would have chosen not to install > an /etc/nanorc at all, but would instead have included the contents of > that file as /etc/skel/.nanorc, so that it gets copied into each > user's home directory at account creation, and the user can edit it > and strip from it anything that is unneeded or unwanted. Debian generally avoid skel files, because they apply only when initially creating an account: There is no (reliable!) way to later update such files for feature additions, typos or even security bugs. On Debian systems, files shipped below /usr/local are owned by the local sysadmin, and files below /etc are dual-owned: Each file is tracked by a checksum, and when a newer package wants to replace one of "its" files, then if checksum of the old file matches then the file is replaced automatically, but if not - i.e. if the local sysadmin has edited the file - then update process becomes an interactive process of asking if the changes should be preserved or file upgraded (or if update process is done non-interactively then the new file is put aside for the local sysadmin to examine later). I do understand that it may seem overkill to have such layered config mechanism, but imagine that I wanted to change copy-paste shortcuts on my systems, and later it is spotted that the open-close shortcuts in the shipped configfile covered the wrong set of dialogs. A new package is released - but what happens to my local edits? If I can locally maintain a config "snippet" containing only the diversions I need, not a full copy of all settings, then my system is more likely to continue working when main configfile is updated. Hope that makes sense. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
