[pacman-dev] Proposed Changelog Feature

Dave Reisner d at falconindy.com
Sat Sep 7 11:47:55 UTC 2019


On Fri, Sep 06, 2019 at 09:51:53PM -0700, Hong Shick Pak wrote:
> Hello!
> 
> I noticed that PKGBUILD supports a 'changelog=' field to specify a file that
> contains release notes for that package and this is query-able via 'pacman -Qc
> <package>'. A lot of software these days maintain a CHANGELOG.md or NEWS file
> that keeps track of notable changes across versions (including pacman).

This isn't how the changelog feature was originally intended to be used.
The intent was for the changelog to be a history of changes made to the
distro packaging, not upstream changes. These days, Arch uses svn/git to
track those changes, so use of changelog has fallen out of favor there.

What you're proposing is actually two-fold:

1) changes in makepkg to allow a changelog that isn't part of the
local packaging files.
2) changes in Arch to generally provide upstream changelogs.

> Would it be possible for the PKGBUILD to allow users to specify a file to set
> for 'changelog=' relative to $srcdir?

This is non-trivial. Consider that something simple in the global scope
such as:

  changelog=$srcdir/$pkgname-$pkgver/NEWS

At the time this var is read, $srcdir isn't yet defined, and while
$pkgver *is* defined, it's subject to change via a pkgver() function.
You can avoid some of this pain if you insist that changelog be partof
the package() function, but that would be highly unusual/annoying.
Alternatives of re-sourcing the PKGBUILD from within user-functions are
equally hard to swallow and probably have strange side effects.

> Of all the packages installed on my system, only 'terraform' and 'powertop'
> have a changelog set. This change would make it extremely trivial for package
> maintainers to specify a changelog file if one exists for a project. I think it
> would be a nice QoL win for Arch users if more packages took advantage of this
> feature.
>
> Let me know if there's an official RFC process for changes! I was not able to
> find any evidence of one.
> 
> Hong


More information about the pacman-dev mailing list