Web lists-archives.com

stretch update overwrites nano file


I am not familiar enough with the Debian bug tracker to add this bug so I hope someone else, who would like to see this fixed as well, will do it for me. ;-)
This is probably not a nano bug but an installation bug, so I have no idea where to look for it if it has already been reported.
I mean like the very first thing I have to enter at the bug search page is which package I want to select bugs. I have to enter some text and I have no idea which text to use for the installation package. The word install returned no reports.
If I enter just "Include bugs with subject containing: nano" I get an error so, can someone else do the hard part a see if this is already in the bug list and if not list it as a bug?

I have several Jessie systems that I am upgrading right now and on those systems I had added a file /usr/share/nano.default.nanorc with the color schema I wanted to use by default. For instance to edit files like \etc\network\interfaces that do not even have an file extention
After the upgrade to Stretch 9.6 using the standard way of updating /etc/aptp/sources.list, the apt-get update and apt-get upgrade (maybe after apt-get dist-upgrade) I noticed my default color schema no longer worked.
The new nanorc config just loads all *.nanorc files in the directory so that was not the problem.
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.

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.
Of course I have backups so I'll just get them from there, but still.

If I have time when doing the next upgrades I will try to tell the upgrade process to not update my nanorc config file and see what that does to the color scheme files. Whether they get replaced anyway or if not and if there are new files somewhere around. But that is just a bit of extra info and does not mitigate this problem.

Bonno Bloksma