[arch-dev-public] New ideas for notifying users about (minor) changes

[Christian Rebischke]

> We already have this feature.
> 
> Add the following to the PKGBUILD, and rebuild it:
> 
> changelog=NEWS
> 
> Now, the user may at any time run the following command for an installed
> package:
> 
> $ pacman -Qc pkgname
> Changelog for pkgname:
> [contents of NEWS file]
> 
> Changelogs are pacman's #1 unused feature. Do note, however, that these
> messages are opt-in and thus users won't see them unless they know they
> need to. As such, it makes sense for a "changelog", but its utility as a
> news bulletin may be in doubt.

Ah ok cool. You didn't mention that `pacman -Qc` part when we talked
about it in the IRC.

One problem what I see with `pacman -Qc` is that we would still need a
wrapper for it, because I don't want to trigger `pacman -Qc` for every
package on my machine manually (or with some bash magic.. I know it's a
one liner).

And I guess it will always print the whole changelog, correct?
The name changelog is irritating as well, atleast I wouldn't expect
minor news in there.

> People should already use decent commit messages. But we should *not*
> abuse them to contain information that is not about what the commit did,
> but instead about how users should respond to the new package release.
> 
> That duplicates the functionality of a changelog without offering a
> compelling use case that it would be better at. It additionally makes
> commit messages *worse* at effectively doing the job of a commit message.

Good points. Another question: How can we enforce better commit
messages? This could be a nice question for the next Arch Linux Meetup,
to discuss.

> That duplicates the functionality of a changelog without offering a
> compelling use case that it would be better at. The only thing that
> would be possible with this, that a changelog cannot do, is tell you
> about the news for a package you don't have installed, but I assume you
> don't actually care about that.

Yep, I think so as well.

> I do not thing we need such a tool, and if we had one, I would refuse to
> use it -- instead opting to use the changelog feature.
> 
> I would still use post_upgrade messages that use vercmp to make sure
> they run exactly once, to alert users to important issues surrounding a
> new release that I do not want them to accidentally miss.

My problem with post_upgrade messages is that it's difficult to differ
between 'breaking notifications' and 'documentations'. If you have a
look into the AUR you will see tons of packages that use the install
files as installation documentation (this is exactly the opposite what I
want). Furthermore if everybody would use such post_upgrade messages, we
would get spammed with it.. If we use them rarely, they are fine, but
for everything bigger they are the wrong solution, imho.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20190730/7307e6d2/attachment.sig>