Arch Linux

this could be fixed by a simple ".install" inside the package with this line :

chown colord:colord /var/lib/colord/icc

or directly in the PKGBUILD

How about simply reading pacman's output and acing accordingly? Why do you need a post-install message for this?

replying at Doug: Pacman just reports a fact, but does not say why this has happened. As said ("why they have a differing ownership"), because I (and likely also other users) would wonder *why* this warning appears. So they need to begin searching (their own directories, package history, diffs, …). Of course, in the first place the pacman warning needs to be understood (complicated by a wrong translation https://bugs.archlinux.org/task/43617 ), and it is not an everyday warning.

That could be saved if the package update would just say "WE messed up, please fix it". Of course, if fixing it automatically (what patrick means, I guess) is safe, that would even be better.

While it may not be an everyday error, it isn't uncommon. I've seen it numerous times (not even counting bugzilla, which gives me dozens of those permission warnings on every upgrade). It's usually trivial to take a look at the package's git log, see what changed, and make the appropriate changes locally. If you take a cavalier attitude to system administration (like so many do), you can just chown the dir and be done with it, who cares why?

replying at Doug: as said, I care and I think caring is the essence of Arch Linux, isn't it? And although I am using Arch since a year this is the first time with this warning.

For me, this is a pair: break something and if you broke it, fix it. Here we have just a break. The fact that there is a break is reported by pacman. To me it is just natural to investigate why there is a unexpected(!) break.

Is that causing any trouble somewhere else to show a message? I mean, what are the downsides (except of some lines of terminal space of "cavaliers")?

Well, this becomes a discussion and not merely report about a bug.

This happens for some packages every few months, sometimes triggered by upstream (often?) or downstream (seldom?).
Possible causes are initally wrong permissions or newly added files by the package, which where formerly maybe created by the software and vice versa.

Pacman itself is acting here correct, it looks after clean and consistend of all packages on the filesystem.
The new package itself is also correct.
If some owner or mode permissions differs, the root user has to care about. Especially because sometimes files could be created by the software itself but later be provided by the package.

I answer here because this happened within 24 hours for libvirt and colord and searched for this unusual accumulation (few months...).
I would be appreciate it, if maintainers of a package handle the individual cases automatically if this is possible without risking breakage. If this is not possible, a short notice which is no merely a warning would be very nice.
A terse and concise message is enough.

I think this bug could be closed?

I guess closing this bug is the best. I realized that adding an advice text would mean that there will be a new package version which means that all people who already updated, get another update, just for this message. That would be annoying for them. I guess the same package version cannot be changed (message added) without creating a new version?!

So, in essence, it just would be beneficial if packagers could take more care of such situations in future, as Peter said, and this bug can be closed as there is nothing useful to do.