Arch Linux

There's not much going on in the PKGBUILDs. Just follow the upstream changelogs.

Well, makepkg and pacman support embedded changelogs. But as long as there is no easy way to autogenerate those I fear this feature will rarly be used.

Upsream changelogs won't tell me what's changed in the latest rebuild of xorg-server 1.5.3-3.

Besides It's not about copying Changelogs from the upstream releases. It's about one simple line saying: I've fixed this and that and it's no longer broken.

Have you considered the fact that the PKGBUILDs haven't been changed at all (aside from the version numbers)? If you really want to check the differences, you can browse the SVN tree here: http://repos.archlinux.org/viewvc.cgi/

Hmm, I'd like a way to automate this, but the big problem is that we'd need to commit the Changelogs to SVN. So the usage pattern is weird:

a) Make changes, build package, test, commit
b) Upload built package to server

If we generate the changelog AFTER we do the commit, we need to rebuild the package. Which is just a headache.

Here's a VERY hacky potential solution: We patch devtools to do the following:
After commit, generate the ChangeLog file via "svn log PKGBUILD > ChangeLog"
We commit the ChangeLog with -m "devtools auto-generated ChangeLog"
We use bsdtar to replace or add the ChangeLog file in the package
Continue with upload as normal

This would work but it's VERY hackish. Any better ideas?

That sounds pretty stupid if you'll excuse me. I think it's fine as it is. IMO, changelogs in the PKGBUILDs have no real purpose. As others have said, if you want the program changelog, look upstream. If you want the PKGBUILD's change history, look at the svn logs.

-1 from me.

I think changelogs in packages should definetely NOT contain upstream changes, and not useless "* v1.2.3-1: upstream update" either.
IMO the only valid changes worth mentioning in embedded changelog are something like:
* v1.2.3-2: changed permissions for /dev/xyz to 600
added foobar group
some-fix.patch added
for example see package changelogs in Debian.
(yes, I know these changes can be seen in our SVN anyway, and info about important changes can be echoed in post_install)

I have an idea that may help us here. We have a newly donated machine from SevenL networks slated to be a build machine. I plan on doing something like the following (may be too much info for those unfamiliar with the way we manage the SVN repo):

* Maintainers commit changes to trunk
* Build machine picks up trunk changes, generates a changelog via 'svn log PKGBUILD > ChangeLog' and builds the package for each architecture.
* If successful, package is pushed to gerolde, containing the generated ChangeLog.

This will do a few things:
a) automate the build step, making Maintainers' jobs easier
b) give us actual ChangeLogs, assuming we enforce better commit messages (can be done afterwards)
c) give us namcap reports for packages and PKGBUILD files for all to see

I know this is going off on a little tangent, but it would definitely solve this issue (and this issue is what gave me the idea)

Opinions?

My only comments it to do with actual testing of a package before it is uploaded. With this scheme, maintainers would need to build a package and test it, then commit it to trunk only to have it rebuilt again and the untested build uploaded.

Or it could possibly be stuck in a staging area somewhere for us to test first...

And will be very informative if last entry of changelog is printed every time (or put enable|disable option in /etc/pacman.conf) when I do "pacman -Suy"

Please make a feature request about this in the pacman section of the bugtracker (if there isnt one already)

Ok, so here's what we'd need to make this complete:
a) a simple way to generate a changelog that isn't too involved. Some of use have 300+ packages, so if changelogs are to be manual, then no one will do it.
b) should we require a packager to add a commit message? devtools adds a simple "upgpkg X.Y.Z" line if no message is specified
c) should we *force* packagers to include a changelog?

I really don't think this is needed... upstream information should be looked for upstream, packaging info is in the SVN log. I still don't get how this is useful information to keep in the package files.

Well, I could see how it would be useful if you are running Arch on a more critical machine (i.e. archlinux.org). If, say, php gets upgraded and I see "removed foobar plugin" which we were using, then I know what to do. It's easy to say "packaging info is in the SVN log, but accessing the SVN log isn't as straightforward. What I'd like to do is get that packaging info into the package itself. All user get the package, but not all of them have svn checked out.

Major changes like that are usually echo'ed in the post-install scripts.

Sure. But that's simply because there was no better method to indicate those changes. It's simply precedent. It makes technical sense to move these items which are "echo"d in a scriptlet to a file that lists all changes.

After generating the changelog, it can be integrated into the
package easily using makepkg -Rf, no need to use bsdtar, etc.