> 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.
signature.asc
Description: PGP signature