On 18 December 2016 at 21:32, Leonid Isaev wrote:

On Sun, Dec 18, 2016 at 02:25:00PM -0600, David C. Rankin wrote:

...

I know this is small-potatoes stuff, but I just wonder if in these instances, it may not be better to either provide pre-update notice or do a post-install script rather than relying on a post update action by the user? At least in the cases where you know up-front that existing functionality will be disabled by the upgrade. (which was apparent from the comment)

Hmm, what about reading /var/log/pacman.log?

​A log is great for figuring out what went happened after something broke, but it shouldn't have to be part of a normal upgrade procedure in my opinion. Personally I do think the provided message was enough though. I'd be a bit scared if package maintainers would add scripts to automatically rename files. This case might have been safe, but in general it is impossible for package maintainers to predict what users may have done to their system and how post-upgrade scripts would interact with that. I'm very happy that Arch lets the user (the one who knows the system best) deal with this type of problem. -- Maarten

On 12/18/2016 04:16 PM, Leonid Isaev wrote:

Update messages are hard to see if they scroll past quickly, or when updating via scripts. On the other hand, pacman.log contains "warning:" lines that show which files were renamed. And why do you believe that logs are only useful post-mortem?

Now, *there's* a simple fix. Don't do automatic updates via scripts. Part of Arch's design is that users should keep an eye on what the package manager does and heed any messages it gives. If the output scrolls past quickly, a post-install message would get lost too, and let's not even get into how bad an idea scripted updates are! There is no change needed. This particular file is no different from all the many many many other files and pacman messages in general that have been *the responsibility of the user* to read end-of-story, since time immemorial. -- Eli Schwartz

Please, never ever seriously consider making pacman surprising in any way resembling to what has been unsuccessfully proposed. Does the pacman wiki suggest running the following line after updates yet? find /etc /opt /usr /var -regextype egrep -regex '\*.pac(new|save)' A section describing the results of this might also hint to why you probably don't need to update your mirrorlist every time, why using rankmirrors is probably not a good idea and that critical stuff like ssh configuration should be dealt with immediately in the cloud, otherwise users might be locked out. Personally I also ongoingly ignore /etc/libvirt/qemu/networks/default.xml.pacnew because it depends on network device name. I think at some point I might have to discuss this with the respective package maintainer. Other than that, I don't like gentoo's way of dealing with this problems other than the fact they ship tooling to actually deal with the 3-way merge pacman expects from the user. I'd welcome suggestions on this and actually was not smart enough up to now to somehow have a script dig up the old version's unmodified configuration file (to be used in said merge). I know there's the pacman cache, but pacman itself doesn't seem to need that to know there's a merge going on. There's definitely potential in doing this that might benefit everyone, please approach me for a follow-up. cheers! mar77i