Re: Debian changelog vs upstream changelog
On Fri, 27 Nov 2009 10:35:34 +1100
Ben Finney <ben+debian@benfinney.id.au> wrote:
> Tony Houghton <h@realh.co.uk> writes:
>
> > What should go in a Debian changelog compared to the upstream
> > changelog?
>
> Well now, there's “should” and there's “should”.
>
> > (a) Confine it to "new upstream release", a list of any closed debian
> > bugs and packaging changes?
>
> Of the options you present, this seems the best interpretation of what
> Debian policy requires:
>
> =====
> 4.4. Debian changelog: `debian/changelog'
> -----------------------------------------
>
> Changes in the Debian version of the package should be briefly
> explained in the Debian changelog file `debian/changelog'. This
> includes modifications made in the Debian package compared to the
> upstream one as well as other changes and updates to the package.
> […]
> =====
It depends on how you interpret "other changes and updates to the
package". I thought it might mean the package as a whole, including
upstream, not just the debian parts.
> So that's the minimum required. I don't consider it sufficient, though.
>
> > (b) As above plus a summary of the most important upstream changes?
>
> This is what I do. Rationale: The Debian changelog, unlike the upstream
> changelog, is available for all Debian packages using standard tools
> *before* installing the package, which as a user is the time I most want
> to see what has changed in a new release of a package.
>
> Merely saying “New upstream version” in the Debian changelog is utterly
> useless to the user for deciding whether they actually want that new
> upstream version on the system.
Good point. Is there not a control field where you can give a URL for an
upstream changelog? I can't remember whether I read about such a thing
along with the recently added Vcs-* fields. If the upstream changelog is
browsable I guess it could help to put a pointer to it in the package
description.
--
TH * http://www.realh.co.uk
Reply to: