Hi Rafi, Am 22.04.2014 um 15:19 schrieb Rafael Ostertag <[email protected]>:
> 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 <[email protected]>: >>>>> 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
smime.p7s
Description: S/MIME cryptographic signature
