Your script

[Dagobert Michelsen]

Hi Rafi,

Am 22.04.2014 um 15:19 schrieb Rafael Ostertag <raos at opencsw.org>:

> 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  …

I was more thinking of

foo (2004-06-14T23:34:30)

  * Initial packaging

 -- 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.

My point was that not version/REV should be in the timemark, but just a real, precise
time, like ISO8601

>> 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 ;)

Because it is progress. The Changelog is for me some documentation of continuous
work which documents larger chunks than a commit but less then a release of the
package.

>> 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.

Having the same format in the changelog is IMHO confusing as it suggests that
a package with the version and REV actually exists/existed.


Best regards

  — Dago

-- 
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2418 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20140422/ac583638/attachment.p7s>