%changelog not in descending chronological order

[Kacper Kornet]

On Mon, Jul 16, 2012 at 03:47:41PM -0400, Jeffrey Johnson wrote:

> On Jul 16, 2012, at 3:43 PM, Kacper Kornet <draenog at pld-linux.org> wrote:

> > On Mon, Jul 16, 2012 at 06:38:10PM +0200, Jacek Konieczny wrote:
> >> On Thu, Jul 12, 2012 at 03:16:02PM -0400, Jeffrey Johnson wrote:
> >>> On Jul 12, 2012, at 2:26 PM, Kacper Kornet <draenog at pld-linux.org> wrote:


> >>>>> That can be because 'git rev-list', used to generate the changelog,
> >>>>> returns the commits ordered by commit date and not the AuthorDate


> >>> Doing qsort(3) on RPMTAG_CHANGELOG* in rpmbuild isn't too hard, might be
> >>> easier than trying to figure out how to trick up git sewage.

> >> I wonder if RPM really needs to enforce the changelog order. Would it
> >> really hurt if it just allowed building a package with such seemingly
> >> unordered entries? Will anything break if we just disable the test?

> > So we have two solutions:

> > a) Switch to show committer dates in changelog. It should be possible to
> > show these dates should be in chronological order.

> > Drawback: for commits migrated from CVS this date is set to some
> > value =~ time of  cvs->git migration

> > b) Patch rpm in PLD to remove enforcing of chronological order in
> > changelog. The patch seems trivial.

> > I would go for b).


> c) qsort the 3 change log tags

That can be done during changelog generation in builder. But I don't
think it is a right solution. In my opinion changelog should reflect the topological
history of development.

> b) will introduce some incompatibilities: for starters,
> there's functionality already implemented to truncate
> change log's by number/oldest that will break if you
> just go unordered.

Do you mean the one build/parseChangelog.c:addChangelog?
It depends how the breakage is defined.
I have just checked and it behaves as expected in case of the
non chronological changelog. If %_changelog_truncate macro is set to a
date it ommits only older commits. All newer one are included
independent of their position in changelog. 

And I think in PLD %_changelog_truncat macro should be set to a number,
not a date.

And there is always a possibility that was used in PLD in CVS. Generate
the text of the whole changelog as a single entry in changelog from rpm
point of view. That way rpm always see only one revision and does not
complain.

-- 
  Kacper