Quoting Benno Schulenberg (2020-02-02 13:44:49) > > Op 30-01-2020 om 11:00 schreef Jonas Smedegaard: > > Please allow local additions without "contaminating" the conffile, > > by adding these lines to the default shipped /etc/nanorc: > > > > include "/usr/local/share/nano/*.nanorc" > > include "/etc/nano/*.nanorc" > > The first include is not a good idea. When the machine admin has > locally built and installed a newer nano, the nanorc files of this > newer nano might be incompatible/unusable for an older nano, so you do > not want to include those files for all installed nanos.
That makes sense, even for Debian. Thanks! > The second include is for a directory that normally does not exist. > If the machine admin has created such a directory, it is on them > to let any relevant nanorc file take it into account. > > So, I would say: won't fix. I understand why you as upstream would not want to provide such hook - as you expect there to be only a single "machine admin" (as you call it) who can just as well edit the master file if needing any changes. I filed this bugreport in Debian, however. I am quite grateful that you follow along there to grab stuff that makes sense upstream, but 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. (this dual-ownership situation is what Debian calls "conffiles") > (By the way, in the upcoming nano-4.8 there will be a new option, > --rcfile=..., that allows the user to specify the one and only > nanorc file to read (which can of course have include statements). > This allows the user to skip an /etc/nanorc that has unwelcome > settings or includes.) Sounds quite nice. This helps do similar but _other_ nifty diversions more elegantly. Please (for debian packaging) still consider my suggestion in this bugreport (or explain to me how I missed your point or in other ways I am misguided). Regards, - 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
