Re: stretch update overwrites nano file

[Tixy <tixy@yxit.co.uk>]

On Tue, 2018-11-27 at 00:30 +0000, Brian wrote:
> On Mon 26 Nov 2018 at 17:03:35 -0600, David Wright wrote:
> 
> > On Mon 26 Nov 2018 at 16:31:38 (+0000), Bonno Bloksma wrote:
> > > What I just DID notice is that the upgrade replaced ALL nanorc
> > > files in the /usr/share/nano/ directory. All ca. 30 default files
> > > with timestamp Jul 16 2014 are gone and my default.nanorc file of
> > > a later date is gone as well.
> > > There are now around 40 files with timestamp Jan 11 2017.
> > 
> > AIUI those files are part of the nano package, so the upgrade
> > upgrades
> > them. It would be nice if one could substitute one's own foo.nanorc
> > file in a location like /etc/nano/ but I don't think the code for
> > that
> > has been written into the program.
> 
> As you say, anything in /usr/share/ is under the control of the
> packaging system and in, this case, "my default.nanorc" is not the
> user's default.nanorc but the system's. It can do what it wants with
> it. There is no bug here.
> 
> > > There was no warning that it was going to do so. Worse there are
> > > NO *.nanorc.dpkg-old files to replace the new color schemes with
> > > my old ones.
> > 
> > I think that facility only takes place for conffiles, and those
> > files
> > aren't conffiles. If they were, they would have to reside under
> > /etc.
> 
> Correct. Why should there be any warning when the packaging system
> is only doing what it is designed to do? A user would alter nano's
> behaviour in $HOME.

For the OP who probably isn't reading the list... The man pages for
nano (command "man nano") says at end "See Also nanorc", and "man
nanorc" says:

    During startup, nano will first read the system-wide settings, from
    /etc/nanorc (the exact path might be different), and then the user-
    specific settings, from ~/.nanorc.

So, the correct file to customise nano settings is either of those two
files.

-- 
Tixy