Your script

[Rafael Ostertag]

Hi Dago
On Tue, Apr 22, 2014 at 01:24:30PM +0200, dam wrote:
> Hi Rafi,
> 
> Am 2014-04-22 08:00, schrieb Rafael Ostertag:
> >On Mon, Apr 21, 2014 at 10:43:43PM +0100, Maciej (Matchek) Blizi??ski
> >wrote:
> >>2014-04-21 22:26 GMT+01:00 Dagobert Michelsen <dam at opencsw.org>:
> >>> I also keep thinking that it
> >>> would be nice to have a dedicated place for the changelog per package in an
> >>> easy-to-parse format (probably in ReST/Markdown?) which could be displayed
> >>> on pkgutil -u (store the previous changelog before removal and diff to the
> >>> newly installed one). Also Catalog changediffs could be generated that way.
> >>
> >>I'm not super familiar with the changelog files, but they seem to have
> >>a well defined format, so we should first look if there already are
> >>parsers. So it might be fine to keep the regular changelog format, and
> >>use a parser whenever we want to process the data. Checking if the
> >>changelog syntax is correct can be part of package checking.
> >
> >There is a parser in cswch (nothing official, I hacked it together), which
> >tries to be compliant with [1]. So cswch has a pretty good idea of
> >changelog.CSW and it should be trivial to convert changelog.CSW into any
> >other
> >format. Let me know what you need.
> >
> >>
> >>I also had this idea that instead of using VERSION in the Makefile, we
> >>could take the latest version from changelog:
> >>
> >>VERSION = $(call extract_version_from_changelog)
> >
> >+1
> >
> >[1] http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog
> 
> I don't think that is a good idea for two reasons:
> 
> 1. The application version (e.g. 1.2) is tightly coupled to DISTFILE and
>    updated only on version bumps.
> 2. The REV is calculated from the date which is good IMHO
> 
> The Changelog should IMHO contain high-level descriptions of changes, like
> "Switch from OpenSSL to GnuTLS" accommodated by a date when the change was
> done.

I don't see a contradiction. Let's see how a changelog might look like. Upon
initial CSW package creation it might look like this:

 foo (0.2,REV=2014.01.01)

   * Initial packaging for OpenCSW.

  -- Rafael Ostertag  ...


Then, a new release comes out:

 foo (0.3,REV=2014.04.01)

   * Upstream graced us with a new release.

  -- Rafael Ostertag ...

 foo (0.2,REV=2014.04.01)

   * Initial packaging for OpenCSW.

  -- Rafael Ostertag  ...


A respin with different configuration options, e.g. the 'Switch from OpenSSL to
GnuTLS', would lead to:

 foo (0.3,REV=2014.04.08)

   * Switch to GnuTLS, because it has no heart.

  -- Rafael Ostertag ...

 foo (0.3,REV=2014.04.01)

   * Upstream graced us with a new release.

  -- Rafael Ostertag ...

 foo (0.2,REV=2014.01.01)

   * Initial packaging for OpenCSW.

  -- Rafael Ostertag  ...


>From my POV, those were all high level descriptions. And they give the user a
clue what has changed. Low level stuff will be in svn or the recipe itself.
Correct me if I'm wrong, or maybe I don't get the point of the changelog.CSW.


> This may not be related to package rebuilds.
Can you elaborate on this? What type of change in the build recipe does not
require a respin? There is none on top of my head ;)

> What may be a good idea is to retrieve the REV timestamp from the change
> log,
> but again rebuilding may result in binary-different packages with the same
> revstamp.
Yes, but is that really of any concern to the changelog? This happens with or
without changelog.

cheers
rafi

> 
> One related thing: It would be nice if we could enable the catalog versions
> on the webpage and have a "svn diff" button between REVs to show the
> Makefile
> diffs as calculated by OpenGrok.
> 
> 
> Best regards
> 
>   -- Dago
>