Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #202792 > unrolled thread

Re: stretch update overwrites nano file

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: stretch update overwrites nano file David Wright <deblis@lionunicorn.co.uk> - 2018-11-27 00:10 +0100
    Re: stretch update overwrites nano file Brian <ad44@cityscape.co.uk> - 2018-11-27 01:50 +0100
      Re: stretch update overwrites nano file Tixy <tixy@yxit.co.uk> - 2018-11-27 08:00 +0100
        Re: stretch update overwrites nano file Brian <ad44@cityscape.co.uk> - 2018-11-27 20:40 +0100
          Re: stretch update overwrites nano file Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-11-28 08:20 +0100
            Re: stretch update overwrites nano file Brian <ad44@cityscape.co.uk> - 2018-11-28 21:50 +0100
        Re: stretch update overwrites nano file Richard Hector <richard@walnut.gen.nz> - 2018-11-28 05:20 +0100
    Re: stretch update overwrites nano file Cindy-Sue Causey <butterflybytes@gmail.com> - 2018-11-27 04:10 +0100
      Re: stretch update overwrites nano file Brian <ad44@cityscape.co.uk> - 2018-11-27 12:20 +0100

#202792 — Re: stretch update overwrites nano file

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.

> 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.

Cheers,
David.

[toc] | [next] | [standalone]

#202796

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.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#202807

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

[toc] | [prev] | [next] | [standalone]

#202838

On Tue 27 Nov 2018 at 11:07:33 +0000, Bonno Bloksma wrote:

[Snip]

> >   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.
> 
> Yup, I simply put my default.nanorc file back into the /usr/share/nano
> dir. I want it to be a system wide default as the current default is
> "a bit sparse" ;-)

Then you used dpkg-divert to be able to sleep better at nights and not
have to worry about it being overwritten?

> I now better understand the logic why my default file got replaced.
> Still it would have been better if there was some kind of warning but
> I understand the logic and I can live with it. :-)

It would not have been better to have been given a warning. Any admin
who alters a system file should know what he is doing and be able to
deal with it. Think of a hundred altered files and a hundred warnings
during an upgrade.

Another point is that /usr/local is the place for non-package files.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#202856

Le 27/11/2018 à 20:15, Brian a écrit :
> On Tue 27 Nov 2018 at 11:07:33 +0000, Bonno Bloksma wrote:
> 
>> Yup, I simply put my default.nanorc file back into the /usr/share/nano
>> dir. I want it to be a system wide default as the current default is
>> "a bit sparse" ;-)
> 
> Then you used dpkg-divert to be able to sleep better at nights and not
> have to worry about it being overwritten?

This is a good advice for the future, but default.nanorc did not exist 
in Jessie's nano package, so there was nothing to divert before the 
upgrade. The OP was unlucky to choose a file name which will was used in 
the next version.

> It would not have been better to have been given a warning. Any admin
> who alters a system file should know what he is doing and be able to
> deal with it.

The OP did dot alter a system file, the file did not exist in Jessie's 
package.

[toc] | [prev] | [next] | [standalone]

#202878

On Wed 28 Nov 2018 at 08:19:39 +0100, Pascal Hambourg wrote:

> Le 27/11/2018 à 20:15, Brian a écrit :
> > On Tue 27 Nov 2018 at 11:07:33 +0000, Bonno Bloksma wrote:
> > 
> > > Yup, I simply put my default.nanorc file back into the /usr/share/nano
> > > dir. I want it to be a system wide default as the current default is
> > > "a bit sparse" ;-)
> > 
> > Then you used dpkg-divert to be able to sleep better at nights and not
> > have to worry about it being overwritten?
> 
> This is a good advice for the future, but default.nanorc did not exist in
> Jessie's nano package, so there was nothing to divert before the upgrade.
> The OP was unlucky to choose a file name which will was used in the next
> version.

No - it is good advice for now, unless the OP wants to continually have
to manage the change manually after an upgrade. I surmise he is happy
to do that.
 
> > It would not have been better to have been given a warning. Any admin
> > who alters a system file should know what he is doing and be able to
> > deal with it.
> 
> The OP did dot alter a system file, the file did not exist in Jessie's
> package.

But it exists now. Choices, choices.

-- 
Brian

[toc] | [prev] | [next] | [standalone]

#202855

[Multipart message — attachments visible in raw view] — view raw

On 28/11/18 12:07 AM, Bonno Bloksma wrote:

> Tixy quoted from nanorc(5):
>
>>   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.
> 
> Yup, I simply put my default.nanorc file back into the /usr/share/nano dir. I want it to be a system wide default as the current default is "a bit sparse" ;-)

Why not put it at /etc/nanorc? The Debian package ships it (it's there
on my system), and expects it to be edited (it's entirely full of
comments). That's what it's there for.

/usr/share/nano appears to be for basic defaults that can be overridden
either at the system or the user level.

Richard

[toc] | [prev] | [next] | [standalone]

#202802

On 11/26/18, David Wright <deblis@lionunicorn.co.uk> 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.


I suppose it would still wipe out a symlink that was hooked to
something under something like ~/.something. In a perfect world, it
would say, "Ewww, I don't know what that is," and keep moving without
touching it..

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* SMH! > Recent eth0 / enp1s0 thread fixed my LAN networking issue in
2 seconds flat *

[toc] | [prev] | [next] | [standalone]

#202816

On Mon 26 Nov 2018 at 22:08:07 -0500, Cindy-Sue Causey wrote:

> On 11/26/18, David Wright <deblis@lionunicorn.co.uk> 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.
> 
> 
> I suppose it would still wipe out a symlink that was hooked to
> something under something like ~/.something. In a perfect world, it
> would say, "Ewww, I don't know what that is," and keep moving without
> touching it..

A non-package file is left untouched by a package upgrade. An admin could
handle an edited package file with dpkg-divert.

  File  diversions are a way of forcing dpkg(1) not to install a file
  into its location, but to a diverted location. Diversions can be used
  through the Debian package scripts to move a file away when it causes
  a conflict. System administrators can also use it to override some
  package's configuration file, or whenever some files (which aren't
  marked as “conffiles”) need to be preserved by dpkg, when installing a
  newer version of a package which contains those files.

-- 
Brian.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web