Through updating debian OS on various hosts (
apt-get dist-upgrade), I've seen many often small variations of the same screen; when a configuration file has been modified, it will tell you a new version is available, and ask you to fix the problem: you've modified the file and apt/dpkg cannot reliably integrate your changes with the new version.
Now this options menu is different between various files. Sometimes even within the same package.
Some files will have a "package configuration" console UI, others will use plain console output. The options available in the package configuration UI are not always the same.
The name of the modified/new version file is not always the same. The location where the new file is stored is not always the place where it should be (sometimes it's in 'tmp'.). The naming scheme for the new file isn't consistent either (some packages use a random name, some use -new, others -dpkg-new, and so on.)
Some packages refuse to tell you where the dpkg default is. Some packages don't provide you with the previous version with extension dpkg-old or -old or -dist or -dpkg-dist or -old-nameofpackage, but others do. (So in some cases you can manually 3-way merge, in other cases you can't). Some packages add a handy 'do a 3 way merge between versions' (which is always the first thing I try as it can often automatically solve the problem: most changes in the config files are usually just typo fixes in comments.
The program or way side-by-side differences are shown can vary between packages/files too.
So I thought the entire purpose of a package management system is to create a consistent way of installing and uninstalling programs. Simple to manage for the user.
What went wrong here; why is this so horrible in its UI/UX? Is there anything a user can do to change/modify apt so at least
- 'do a 3-way merge' is available
- The new files are always renamed/placed in a consistent way?
Having to re-read and figure out exactly what to do with each and every config file manually because of 1,000 tiny variations of doing the same thing when it boils down to the same rote procedure is painful.
To illustrate what I mean, here's two from an upgrade;
Configuration file '/etc/ssh/ssh_config' ==> Modified (by you or by a script) since installation. ==> Package distributor has shipped an updated version. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : start a shell to examine the situation The default action is to keep your current version. A new version (/tmp/tmp.3RoEfdEm3M) of configuration file /etc/ssh/sshd_config is available, but the version installed currently has been locally modified. What do you want to do about modified configuration file sshd_config? install the package maintainer's version keep the local version currently installed show the differences between the versions show a side-by-side difference between the versions show a 3-way difference between available versions do a 3-way merge between available versions start a new shell to examine the situation
Those options in the second variant? They're not always there in that order.
It feels almost like this is just made to trip you up.