packaging nano with a skeleton nanorc file

[Benno Schulenberg]

Op 14-09-2020 om 08:37 schreef Kamil Dudka:
> On Saturday, September 12, 2020 7:37:02 PM CEST Benno Schulenberg wrote:
>> True.  But if users choose to do rolling upgrades from one version of an
>> operating system to the next, without reinstalling, then this probably
>> means they are rather attached to their configurations and setting, and
>> do not want them to change in any way.  Thus they might become aware of
>> new features of programs only when they have to install the OS on a new
>> machine.  There is no harm in that.
> 
> Fair enough.  The problem is that nano has been packaged this way since 2015. 
>  
> If we moved the line `include "/usr/share/nano/*.nanorc"` from /etc/nanorc
> to /etc/skel/.nanorc , we would disable syntax highlighting exactly for the
> users that do not want to change anything.  Do you have any idea how to make 
> the transition any smoother?

You wouldn't move the line.  The new package wouldn't install an /etc/nanorc
file at all.  When upgrading a package, do all files installed by the old
package get removed first?  If yes, is there no way to tell the installer
to leave the files in /etc alone?  (I think in Debian this is the default
behavior: remove the package but leave the configuration files in place.)

The idea is that users who do a rolling upgrade will retain their /etc/nanorc
(and will not get a .nanorc from the skeleton because that is only for newly
created users), and on a new install there will be no /etc/nanorc and just
the ~/.nanorc from the skeleton.  But... this will not work on a multi-user
machine: new users would get the skeleton ~/.nanorc but the still-present
/etc/nanorc would affect them too.  :|  I see no solution for this case.

> I am not sure whether it was mentioned here but nano is going to be used
> as the default editor in Fedora 33:
> 
>     https://fedoraproject.org/wiki/Changes/UseNanoByDefault

Nice.  The example of git, though, is not a very good one, I think.
People who use git on the command line probably know a bit about shell
things and environment variables.  But true, if they try git for the
first time, it's much better to land in nano than in something like vi.

(If the user has 'set positionlog' in their ~/.nanorc, doing a later
'git commit' will put the cursor back where it was left in the previous
commit message.  In most cases, this is annoying.  So in my ~/.gitconfig
I have under [core]: editor = "nano --guide=74 +1", where +1 places the
cursor at the start of the message.)

> So Fedora users are going to be more sensitive to unexpected changes in nano 
> from now on.

I see.

Benno

signature.asc
Description: OpenPGP digital signature