On 7/29/19 6:47 PM, Christian Rebischke via arch-dev-public wrote:
Hello everybody, I got assigned to this issue here:
https://bugs.archlinux.org/task/62823
The users would like to have a notice in pre/post install/upgrade notifications via pacman .install files.
I am not a fan of spamming such news via pacman and I think the installation/upgrade process should be clean of such messages, but I don't have access to the news tool on our website as well.
It's not unreasonable to add such post_upgrade messages in cases where you want to ensure the user sees the message.
So what can we do here? I am a big fan of Gentoos Newsletter feature[1]. It would be super awesome if we would have a tool such like `archnews <packagename>` to retrieve NEWS about a certain package from an endpoint. This endpoint should be controllable by every maintainer (devs and TUs included). I discussed this with coderobe a bit and we came to different solutions:
Solution 1: a NEWS file inside of the package repository: --------------------------------------------------------
A maintainer could upload a `NEWS` file into the package repository and then a client could grab this information directly via downloading the file from:
https://git.archlinux.org/svntogit/community.git/plain/trunk/NEWS?h=packages...
Pro: + every maintainer could control this NEWS file easily via our current tools. + It's easy to download the NEWS files (we can expect new tools from the community)
Con: - We bloat our repository
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.
Solution 2: commit messages as NEWS ------------------------------------
The maintainer could/should put such news into the latest commit message.
Pro: + no extra file + using existing infrastructure + one workflow
Con: - I need an actual change in the repository to create a new NEWS object (If we have a look on my example with strongswan, I would need to add something in the PKGBUILD to make a new commit to make a new NEWS object) - It's more difficult to get with tools. The user needs to checkout the repository (in solution 1 it can be just a curl call)
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.
Solution 3: A webapp on news.archlinux.org with a fancy UI -----------------------------------------------------------
This solution would be the most work. We could have a new webapp (such like our security tracker) just for NEWS objects. Every maintainer should have access to their assigned packages.
Pro: + Fancy + Easy to use + API endpoints
Con: - A lot of work -------------------------------------------------------------
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.
I would go for solution 1. What would be interesting to know for me:
1. Do you think that we actually *need* such a tool? 2. Would you use such a tool/workflow? 3. Do you have other/better ideas?
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. See community/sigil for an example of using post_upgrade for warnings that I want all users to see. See community/fanficfare for an example of using changelogs to make the list of changes in the package, more accessible. -- Eli Schwartz Bug Wrangler and Trusted User