← Back to team overview

pkgme-devs team mailing list archive

Re: Changelog handling

 

On Nov 17, 2010, at 05:04 PM, James Westby wrote:

>I just put up a merge at
>
>  https://code.launchpad.net/~james-w/pkgme/basic-changelog/+merge/41106
>
>that adds basic changelog handling, which is required to be able to
>build a source package.

I commented on the code there.

>It just stomps on any existing changelog and puts a single stanza that
>has the current version.
>
>There are two things arising from this.
>
>The first is that there is a new required bit of info for backends to
>provide: "version", which is the current (upstream) version number.
>
>Second, is what we want to do with the changelog long term. How would
>you want the changelog to be maintained?

From my own limited data set, my sense of it is that once the initial
changelog entry is written by the tool, subsequent changelog updates will be
handled in the traditional way, e.g. dch.  I also think that there should
almost never be an existing changelog to squash.  And also, your initial
changelog entry will very often be something like:

flufl.enum (3.0.1-1) unstable; urgency=low

  * Initial release (closes: #588857)

 -- Barry Warsaw <barry@xxxxxxxxxx>  Wed, 03 Nov 2010 15:48:49 -0400

Therefore:

 * pkgme should complain when there's an existing debian/changelog and by
   default refuse to overwrite it.  Perhaps a --force would be helpful.

 * pkgme should prompt (or otherwise encourage) a debian bug number for the
   initial release of a package.

-Barry

Attachment: signature.asc
Description: PGP signature


Follow ups

References