Then I modify my suggestion to have the files renamed to "filename.something.sample", like smb.conf.sample in the Samba package.

The default rc.local file does literally nothing but act as documentation. I see no scenario where overwriting something with nothing would be desirable.

The same goes for /etc/ntp.conf; it contains useful hints about the various parameters, but by default it configures an NTP server that syncs with itself, which is actually worse than nothing.

There are a few other examples as well.
I don't think that would be feasible, to be honest. The complexity required for handling various types of config files differently would probably require a change to the package files themselves.

However, if some select config files were converted to .sample files, it would significantly lessen the risks involved in selecting "overwrite all".

Now that's something I agree with. It clearly demonstrates that *.sample is more of a documentation of what is possible. And it also documents the fact that user modifications should take priority over the package-supplied version.

Technically, it already kinda does, especially for config files which is what we're discussing:But yes, I'm being pedantic and I do understand your position.

gdk-pixbuf-2.42.0
https://download.gnome.org/sources/g...-2.42.0.tar.xz

Here are some notes about gdk-pixbuf:

I'm too lazy to look and see how Pat does it in official packages, but the SBo template for the doinst.sh script checks the md5sum of the contents of the old and new conf file and if they're the same, they discard the new file:

Even better

No, I mean if I:

1. Install a package. This package moves the *.new file into place. I don't edit it.
2. Upgrade the package, which includes a new version of the configuration file. upgradepkg will leave the *.new file in place, as the *.new file is different than the already-existing configuration file.
3. I must compare the files and remember that all the changes are due to the package itself, not to custom changes I've made.

The use of tools such as etckeeper (https://slackbuilds.org/repository/1...tem/etckeeper/) can assist the user in these cases. Also, more and more software is making use of the *.conf.d/ convention which allows users to separate out local and package-managed configuration options.

Edit to add: But unless someone comes up with a really elegant solution, it's not worth talking about. The status quo works well enough. We're not upgrading tens of packages each week, after all. It really is minimal effort to manually review all the *.new files.

@drumz: it is very rare that an upgrade of a package brings a modified configuration file. But if this is the case, it is worth being aware of that and spotting the differences. I don't think that in this case just replacing the old config files (even if not edited by you) by the new one be a good idea, as the new config file could include settings of new variables that you better be aware of.

1 members found this post helpful.

I believe the argument is that if you were using the Slackware defaults previously, it's reasonable to conclude that you'll want to keep doing so.

1 members found this post helpful.

I understand what you're going for here, but I certainly didn't get that from your previous post (although, re-reading it with context I can see what you mean now).

It would basically be impossible to do this unless a checksum of the original file was kept somewhere and compared to the checksum of the current config when a new config is presented.

etckeeper can be handy to track changes (and I've used it for years), but it wouldn't let you know if the file has been modified from the one included with that package unless you update the repo when installed and update it again if/when any changes are made (I'm horrible about keeping my etckeeper up-to-date) and then you'd need to check the log for any changes to that file.

Even then, as a distribution maintainer if I bring a new feature of which users would only benefit through a new setting I'd like users be aware of that. Been there, done that. I can write a note about the change in a ChangeLog but not all users will read it. I can inform through a mailing list but not all users are subscribed to it.

The config files are in the package tree at the location they will be installed to. It is possible that these "default" config files have changes I might want to merge in to my existing config file. If I remove them and rely on doinst.sh to generate this default file if, and only if, the file doesn't already exist, how will I be able to compare these changes.

If your removing these config file from the package tree, how will doinst.sh handle their generation if needed in your scenario? Add the config files to doinst.sh? I sure hope not.

I am fine with the current method of handling config files.

rc.local is not that big a hassle. 'p'rompt, 'm'erge, 'l', 'i'nstall. Now cups on the other hand...

1 members found this post helpful.

The whole point was to do this only for files that are really just documentation.

But you're still right; if nothing else there might be relevant information in the newer versions of the files. Giving them a .sample extension is looking more and more like the ideal solution.