In fairness, people should never blindly accept all the changes if they know they've made changes to files in /etc/. That's just asking for trouble. I *ALWAYS* select "prompt" and check through the diffs to see if the files are ok to overwrite, if I can ignore the changes, or if I need to manually adjust the files (there's changes from upstream to the config and I've made my own changes to the config).

I don't have any problems if the placement of rc.local and other files were adjusted to prevent accidental overwriting (I'm fine with keeping it the same or switching to the .sample proposed in this thread), but if accidental overwriting does occur, that's on the part of a poor sysadmin blindly accepting config changes without review. That's just a recipe for disaster.

I wonder if a better argument could be for slackpkg to ignore certain .new files or to allow users to blacklist certain .new files from being handled by new-config.

5 members found this post helpful.

Thank you bassmadrigal. I hadn't tried "prompt" which may go a ways toward what I'd prefer. Currently I choose "do nothing" and try to find them all before I reboot to see if any substantive changes have been made.

Speaking of which, and maybe a topic for another thread, as much as I love CLI (even more now since I learned about fzf), when doing batch work like searching for and editing numerous .new files, I still prefer a good file manager. I very much like Dolphin but I have yet to discover how to get it's "Find" function to allow wildcards. Obviously that would help a lot when all I want to find is *.new files within a specific directory structure, but one with many subdirectories. Do you know how to get wildcards enabled there?

@enorbet: dotnew-gtk does what you want: https://github.com/gapan/dotnew
You made me realize that George converted the UI to Python 3 recently, so I will upgrade :-)

Most Slackware packages that drop .new files have this stanza in the doinst.sh script.
If the incoming .new file is the same as the existing file, it is automatically removed.
If the existing file is different then "leave the .new copy for the admin to consider...".

So, if you see a .new file, then either you have made a customisation in the existing file and/or there have been changes. These need to be reviewed.

Personally, I never make these changes in a GUI environment, an old habit from when changes in X could be problematic.

Running 'slackpkg new-config' will find any .new files and allow you to work through the list, choosing either 'Remove' (to remove the incoming .new file) or 'Overwrite' (to overwrite the old with the new). Like @bassmadrigal, I always use the 'Diff' option to look at changes and then may use the "Vimdiff' option to merge old customisations into the incoming .new file before doing an overwrite.

The rc.local.new thing is a storm in a teacup. It can be useful to check that your customisations are as you want.

I have a rc.local with several entries in it. When there is a rc.local.new, it is only four key strokes to take care of things for rc.local

"p" (P)rompt K, O, R selection for every single file
"m" (M)erge
"l" # (L) to merge the left side with my changes
"i" (I)nstall the merged file

With the slackpkg beta version, the files with ".new" are listed for you.

1 members found this post helpful.

For the few files like rc.local where one is very unlikely to ever want the stock version to replace a user's custom version, the obvious answer is to have the doinst.sh only move it into place if the target file does not already exist and delete it otherwise.

Having said that, it's not that onerous living with it the way it is: I see rc.local.new, I 'rm'. No need to even look.

2 members found this post helpful.

This thread remembers me of a famous debate at Vatican, where the cardinals argued (for several years) if the angels have two or four wings...

WTF people? So, everything works perfectly in -current?

Then, let's ask our BDFL to be kind to upgrade ICU without fallbacks!!!!

Cool idea, maybe the opposite also with a list of .new config files that could be automatically overwritten (for programs where default config is fine). But I am fine with the current way though

Nothing breaks in stock -current when ICU is upgraded.
What breaks is third party packages, for which you took responsibility when you installed them.

1 members found this post helpful.

I sometimes skip the .new's during the upgrade process and come back to them later via $ slackpkg new-config which looks for all the .new's and offers the prompt option.

A good option is to run $ slackpkg new-config with prompt in one terminal and run mc (Midnight Commander) in a second terminal to compare and edit the changed config files - CTRL-x CTRL-d (diff) and F3 (View) or F4 (Edit). mc has a lot of searching and filtering features too. Or use a Mac with the excellent ForkLift app (similar to mc) + Kaleidoscope (diff app) and diff and edit the Linux config files via ForkLift SFTP connections .

2 members found this post helpful.

Please forgive me as I hadn't explored "P" for Prompt. It appears it and dotnew-gtk (thanks Didier) do what I really needed most, just to list so I know what I was about to ignore or overwrite and not be forced into a blind choice. That definitely smooths out workflow. I know... I'm obsessive about feedback. I hate it when an operation that takes more than 30 seconds doesn't keep me informed that it's working and sometimes even what it's working on. As Popeye said, "I yam what I yam".

My apologies if I dragged anyone through my mud, but I did learn cool stuff as a result. Hopefully at least someone else did too.

Had same problem with rc.local and rc.mysqld... After some restores i used chattr +i and since then I don't care if I press wrong letter after upgrade. And it's lesser evil to chattr -i, edit, chattr + than to dig trough backups

1 members found this post helpful.

A similar bother for me is when the system asks me to consider a .new file that only differs from the existing one in terms of customizations I have personally made to the existing one. (In other words, the "upstream" config file has not changed.) I went so far as to make some mods to installpkg in the past to prevent this from happening. But it's a non-trivial thing to change, requiring some sort of record of the "upstream" config file to be stored on the system, and Pat was understandably not interested in changing the behavior, so I moved on.

1 members found this post helpful.

Everyone here seems to be missing the fact that from a packaging perspective, it makes 100% sense to use "*.new" config files.

There is no possible way for the package builder to know what changes you've made, so it's up to you to decide what you want to keep.
It's not difficult.

Difficulty wasn't the issue. Timing was. I didn't want to locate AFTER a blind choice was made. I wanted to make an informed choice in realtime (before they were written) and Prompt does a decent job at that.

2 members found this post helpful.