ChangeLog for packages

[pierce.jason]

gslapt and slapt-get both support downloading a repository ChangeLog.txt

Repo tools can be used to automatically create this file, based on packages added/removed/updated to the repo.
These tools can also automatically create a RSS feed !

There are a few different basic formats that various Slack distros are using for ChangeLog.txt. It is most common
to just see the category/package name and version, along with weather it is an upgrade or new package.

Such as used on slackey.eu:
added :: cellwriter-1.3.4-i486-5sl.txz
recom :: grub-legacy-0.97-i486-4sl.txz
upgraded :: orc-0.4.13-i486-1sl.txz

In a slightly different format, LinuxPackages.net and Salix use entries in ChangeLog.txt as such:
a/attr-2.4.45-i486-1.txz: Upgraded.
isolinux/initrd.img: Rebuilt.
a/sysvinit-scripts-1.2-noarch-42.txz: Rebuilt.

All of the formats presented here can be generated automatically when PACKAGES.TXT is being created, with no additional packager/repo-maintainer feedback.

[pierce.jason]

In addition to the formats in the original post, there are some extended formats available that can give very usefull data to an end user and developers alike.

Here are a few examples from Salix showing usefull extended information:
xap/gslapt-0.5.3a-i486-2gv.txz: Rebuilt. Patched for fixing gslapt
  freezing sometimes when upgrading packages. Thanks laprjns and malloc.
l/libiodbc-3.52.7-i486-1tm.txz: Removed. Package is included in
  Slackware.
xap/ktsuss-1.4-i486-2gv.txz: Rebuilt. Patched for localization support.
l/gtkglext-1.2.0-i486-2gv.txz: Added. Needed for celestia but was
  missing from the repositories. Thanks for the report lupinix!
ap/hplip-3.10.2-i486-2gv.txz: Rebuilt. Added hpijs back into the
  package. Thanks Shador!
games/openttd-1.0.3-i486-2cd.txz: Rebuilt. Patched to fix
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4168
xap/pcmanfm-0.5.2-i486-2gv.txz: Rebuilt. Removed the "Open folder as
  root user" menu entry, since it was broken. Thanks emgee_1 for the
  report.

To me as a system administrator, those last two examples are the most interesting. An option disappearing, or being added to a program is a great thing to point out to users as they are upgrading. And of course being aware of the details of security fixes is of great interest to many admins.

Especially for the security notification in the ChangeLog, LinuxPackages.net uses a very nice format for this. It appears that security-related ChangeLog entries are generated from a template, by just plugging in some data to it. Makes for a very nice, predictable, parse-able format for security-fixes:
l/polkit-0.101-i486-2.txz: Rebuilt.
Patched to fix a race condition that could allow a local user to execute
arbitrary code as root. Thanks to Neel Mehta of Google.
For more information, see:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1485
(* Security fix *)
a/acl-2.2.50-i486-1.txz: Upgraded.
Fix the --physical option in setfacl and getfacl to prevent symlink attacks.
Thanks to Martijn Dekker for the notification.
For more information, see:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4411
(* Security fix *)
l/libtiff-3.9.4-i486-2.txz: Rebuilt.
Patched overflows that could lead to arbitrary code execution when parsing
a malformed image file.
For more information, see:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0192
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1167
(* Security fix *)

The example entries in this post aren't generated fully-automatically like the basic ChangeLog.txt could be. The detailed information would have to be somewhat-manually added to the generated ChangeLog.txt

[pierce.jason]

As I understand it, most repos using Extended Data in their ChangeLog.txt are entering the details completely manually.

One way that could help overcome this overhead in repo-management would be to read a file from the package its self. Similar to
how we have a slack-desc and slack-required to assist in repo-management. In addition to other non-essential install/* files
such as slack-suggests and slack-conflicts, there could be a slack-changes.

In this case, when a packager feels that there is a significant change that the end-user should be made aware of it can simply be entered here. Then when creating the ChangeLog.txt, the latest entry to slack-changes could be pulled out and automatically inserted.

Something like this could be the start for an install/slack-changes file:

* version 0.4:
    - add --since (-s): print today installed packages
    - add -u to use with -s: print installed packages since a choosen date
    - change the date format of the twalog file to be more internationnal
    
* version 0.3:
   - add --remove (-r) to use with -n : remove the last N installed
    packages.
    - use spkg by default else removepkg for removing packages
    - add cron job

This is likely slightly too verbose to go into ChangeLog.txt, but serves as a decent example of the idea. Perhaps the first line after the version number could be a summary which is entered into the ChangeLog.txt.