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