LinuxQuestions.org - keep old or install new configuration files during slackpkg upgrade-all ?

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - keep old or install new configuration files during slackpkg upgrade-all ? (https://www.linuxquestions.org/questions/slackware-14/keep-old-or-install-new-configuration-files-during-slackpkg-upgrade-all-708508/)

keep old or install new configuration files during slackpkg upgrade-all ?

Is it best to keep the old, or overwrite with the new configuration files which are found during a "slackpkg upgrade-all", run in a terminal as root for the newer software packages? First "slackpkg update" is run, and then I run; "slackpkg install-new", and last that upgrade-all command. And here is that tool; http://sourceforge.net/projects/slackpkg/

It depends if you have modified any of the configuration files. Slackpkg gives you the option to prompt for each file and to look at the differences. This will give you the information you need to make your decision.

samac

I did try the prompt option, and then the (D)differences option for the first package. Then I could not enter any more commands in that terminal window since the "user-name#" cursor was not there to type, it just had a small box at the bottom of the terminal, so it was like stuck then ?

at that point you decide whether to keep or overwrite. I usually keep the old file and merge in any changes by text editor.

samac

To find all the .new config files run:

Code:

find /etc -name "*.new"

To update the .new files run:

Code:

mv /etc/file_name.new /etc/file_name

Or, if you skipped some .new files (used the option "K"eep), you can let slackpkg search for them again later with

Code:

slackpkg new-config

Personally I always keep the configs. Those configs that are unchanged between the new and the old packages are merged in principle anyway (see the doinst config() function in most packages).

Other than that, like I said, I keep the configs and as root I run `find /etc/ -name "*.new"' and diff all files by hand and then decide if they need to move over. I have found that colordiff (available at SlackBuilds.org) really makes things easier on my eyes there as well.

A very direct way to maintain new configurations in Slackware

This hasn't been updated in over a decade so maybe this will help someone or spark more efficient ways to maintain configuration files in Slackware.
A very simple revision control method may help keep configuration files sorted
out and available for comparison with new revisions.
More sophisticated methods exist using svn, mercurial, or even git, but this is
a very straight forward method.
A script may ease the process of processing new configuration files.
This could be automated further, but this a very basic way.

In this method, configuration file revisions are saved using the file modificaton date.
For example, a revision of a file
file.conf
is saved in the current directory as
file.conf.YYYYMMDD_hhmm
The more time consuming steps of this method involve retrieving and adding the
modification date.
A script can help here.
A script named cnm.sh was created to reduce the number of steps to create
revisions of configuration files.

Code:

#!/bin/bash

# file: cnm.sh

# date: 20240303

# desc: Make a copy of a file with a name using the modify date

# note: This script lives at /usr/local/sbin

# note: This script must be run from the command line as sudo

#      if in a system directory.

# note: make cnm.sh executable: sudo chmod +x /usr/local/sbin/cnm.sh

fname=$(basename -- "$1")

fext="${fname##*.}"

# echo $fext

if [[ $fext = "new" ]]; then

        cp -afp $1 `ls $1 | sed 's/\.new$//'`.`date -r $1 "+%Y%m%d_%H%M"`

else

        # Can't use $fname with filenames like slackpkg.conf

        cp -afp $1 $1.`date -r $1 "+%Y%m%d_%H%M"`

fi

The following is an example session which uses this script.

An upgrade with slackpkg may report several configuration files require attention.
Packages that had configuration changes
/etc/postfix/access.new
/etc/postfix/canonical.new
/etc/postfix/generic.new
/etc/postfix/header_checks.new
/etc/postfix/relocated.new
/etc/postfix/virtual.new
/etc/slackpkg/blacklist.new
/etc/slackpkg/mirrors.new
/etc/slackpkg/slackpkg.conf.new

So an example of a comparison and revision update session can be:
cd /etc/postfix/
sudo cnm access # make access.20230903_1339
sudo cnm access.new # make access.20240307_1458
sudo vi -d access access.new # modify access with access.new as necessary
sudo mv access.new access # or just replace with the new version

The as found listing for the postfix/access configuration files:
$ ls -l access*
-rw-r--r-- 1 root root 21111 Sep 3 2023 access
-rw-r--r-- 1 root root 21147 Mar 7 14:58 access.new

The as left listing for the postfix/access configuration files:
$ ls -l access*
-rw-r--r-- 1 root root 21147 Mar 7 14:58 access
-rw-r--r-- 1 root root 21111 Sep 3 2023 access.20230903_1339
-rw-r--r-- 1 root root 21147 Mar 7 14:58 access.20240307_1458

Most configurations are not uniquely modified and can be simply updated.
A quick review of the changes is always warranted prior to updating.
tkdiff is useful in these instances.
sudo cnm canonical
sudo cnm canonical.new
tkdiff cononical cononcial.new
sudo mv canonical.new canonical

sudo cnm generic
sudo cnm generic.new
tkdiff generic generic.new
sudo mv generic.new generic

sudo cnm header_checks
sudo cnm header_checks.new
tkdiff header_checks header_checks.new
sudo mv header_checks.new header_checks

sudo cnm relocated
sudo cnm relocated.new
tkdiff relocated relocated.new
sudo mv relocated.new relocated

sudo cnm virtual
sudo cnm virtual.new
tkdiff virtual virtual.new
sudo mv virtual.new virtual

Some new files are identical to existing revisions and are removed.
cd ../slackpkg/
sudo diff -s blacklist.20210531_1624 blacklist.new
Files blacklist.20210531_1624 and blacklist.new are identical
sudo rm blacklist.new

sudo diff -s mirrors.20240308_0939 mirrors.new
Files mirrors.20240308_0939 and mirrors.new are identical
sudo rm mirrors.new

Quote:

Originally Posted by linux91 (Post 6488496)

Code:

#!/bin/bash

# file: cnm.sh

# date: 20240303

# desc: Make a copy of a file with a name using the modify date

# note: This script lives at /usr/local/sbin

# note: This script must be run from the command line as sudo

#      if in a system directory.

# note: make cnm.sh executable: sudo chmod +x /usr/local/sbin/cnm.sh

fname=$(basename -- "$1")

fext="${fname##*.}"

# echo $fext

if [[ $fext = "new" ]]; then

        cp -afp $1 `ls $1 | sed 's/\.new$//'`.`date -r $1 "+%Y%m%d_%H%M"`

else

        # Can't use $fname with filenames like slackpkg.conf

        cp -afp $1 $1.`date -r $1 "+%Y%m%d_%H%M"`

fi

Nice! I think the git approach is very nice! I used only for my personal dotfile but I think the same idea for configuration files.

I always choose K after # slackpkg upgrade-all.

I always choose prompt, eventually diff, then overwrite or merge.

It may be cumbersome following -current if you let a few weeks between updates. Still, makes me feel secure.

Why not just use etckeeper (wrapper that uses git by default and adds file metadata, etc) from SBo? I've been using it for years now.

https://slackbuilds.org/repository/1...arch=etckeeper

Many tailored configuration files are modified in ways that merging with a new file is difficult to automate, and will not provide a workable result. It seems that 'vi -d cnfg cnfg.new' has worked for the most part.

Quote:

Originally Posted by james2b (Post 3462040)

Is it best to keep the old, or overwrite with the new configuration files which are found during a "slackpkg upgrade-all"

It's not just upgrade-all, if you "upgrade" a single package or list of packages and there are changes to configuration files you will also be prompted.

The key is to know what configuration files you have made changes to. If you are using slackpkg-15.0.10, then you will see a list of files that have changed shown before the prompt. If you are certain that you have not made any changes to any of the listed configuration files then (O)verwrite should be the favored option. If you make a mistake, all is not lost. By default slackpkg backups up the original configuration file with the *.orig extension (ORIG_BACKUPS=on in slackpkg.conf). If needed you can merge needed changes in to the overwritten configuration file manually. Same applies to (K)eep, the *.new configuration file then be merged manually with the unchanged configuration file. I use (P)rompt if there are not a lot of changes and select (K)eep, (O)verwrite, (R)emove, (D)iff or (M)erge as needed (I've never tried using vimdiff) for each configuration file. If there is a boatload of changed files I will select (O)verwrite to enure changes to configuration files I have not modified are made and make adjustments to the configuration files I have modified using the backup. I use the (K)eep option mostly on configuration files that I know merge does not do well on. I merge those manually. I rarely use (R)emove, but the are times when it's appropriate.

One thing I try to do with all configuration files is to made the changes "friendly" for merging so that only the changed line(s) or added line(s) appear in the merge for picking left or right. Occasionally a manual edit/merge is required.

One of my favorite tools for doing merges between two configuration files not being handled by slackpkg is mc for *.new or *.orig files.

I tried to diff/merge but it was too difficult to figure out, so I had to keep configuration as I had and then compare/contrast changes and update manually.