1

I like the way Debian gives various changelogs. For instance for most packages it has

  • changelog.gz, the upstream changelog giving details of the differences between any two versions or at times even point versions. Nowadays usually distilled from $ git shortlog or whatever equivalent command in whatever VCS is being used.

  • changelog.Debian.gz, listing changes/improvements done to a package. Some of the common changes include changes of the packaging team, changes to the standards versions, updating build-depends, any patches which fix some issue in Debian which has not been accepted upstream, any changes to either debian/rules or debian/control which might be notable and need mentioning.

While I'm pretty happy with the way Debian organizes this, I'm wondering whether this idea of having separate changelogs, tracking upstream changes separately from distribution changes to lessen confusion, came from Debian or some other distribution. Was Debian the first distribution to do this? If not, where did the idea come from?

0
2

Debian wasn’t the first distribution to separate the changelogs, but it might have been the first to maintain per-package changelogs.

Changelogs for software have existed for a long time (they’re a fairly obvious variant of lab notebooks or engineering logs). Early Linux distributions kept their own changelogs in a similar fashion; since they logged changes made to the distribution, they were naturally kept separate from the changelogs of the software being distributed. For example, SLS had a changelog with entries like

920901: Initial release (.96p4).  Didn't use jump tables though.

921007: Release .98p0.  Jump tables used.

921011: menus.taz: new sysinstall and sysbuild.
        a1: New .98p1 image with new sysinstall
        a2: New rootdisk
        image.taz: 0.98p1 kernel, Fixed top.
        devs.taz:  modified /dev directory
        image.taz: Linux .98p1 image, ps, etc.
        lx96p1.taz: Linux source for .98p1 (replaces lx98.taz).
        tcpip.taz: Telnet and fpt 2.2.2 binaries.
        c4/: Added new disk, clisp to compiler series.
        x*: Reorganized and fixed double compressed fonts.

The earlier MCC also had changelogs, for example this one for 0.99p8.

Users familiar with Slackware will find the format familiar; Slackware still maintains distribution-wide changelogs.

For both SLS and Slackware, a single distribution changelog made sense because they were both initially the work of one person (Peter MacDonald for SLS, Patrick Volkerding for Slackware) and changes were thought of in terms of the whole distribution, not individual packages (at least, not to the same extent as nowadays).

As you found out in the mailing list discussion on debian-devel, the current changelog practices in Debian weren’t present right from the start. In early 1994, Debian 0.91 had a distribution-wide changelog and its packages don’t contain a changelog (at least, not its binary packages). By late 1994 and Debian 0.93, source packages had individual changelogs, kept in debian.README (which also contains licensing information); see LILO’s packaging patch for an example:

Changes

9-July-1995 Bruce Perens <Bruce@Pixar.com>
    Upgraded to version 16.

23-December-1994 Bruce Perens <Bruce@Pixar.com>
    Added Debian GNU/Linux package maintenance system files, and configured
    for Debian.

(Note that looking at packages such as dpkg or the Debian documentation, as suggested in the mailing list, isn’t all that useful since they are native packages, with a single changelog covering software and packaging changes.)

So it seems Debian was the first Linux distribution to store per-package, distribution-specific changelogs, separate from the upstream changelogs. Other distributions followed suit, at least partially, with e.g. RPMs storing changelogs in their spec file (albeit typically with less detail than Debian changelogs, and only in the source package). There might be similar practices in the BSD world, I haven’t checked; and I can’t remember what packaging initiatives, if any, were around for other Unix systems in the early nineties.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.