Trimming (or obsoleting) %changelog?

Alex G. mr.nuke.me at gmail.com
Sat Apr 20 04:44:43 UTC 2013


On 04/19/2013 09:44 PM, Adam Williamson wrote:
> On 19/04/13 06:16 PM, Alex G. wrote:
>> On 04/15/2013 05:30 AM, Richard Hughes wrote:
>>> Is there any guidance as when to trim %changelog down to size? Some
>>> packages have thousands of lines of spec file dating back over 15
>>> years which seem kinda redundant now we're using git.
>>>
>>
>> I've always seen the %changelog as a relic from times when we didn't
>> have reliable source SCMs. For me, it is redundant (and boring) to have
>> to update the %changelog, while I have the exact same information in the
>> git history.
>>
>> I think the best way to go is to obsolete %changelog, and extract the
>> changelog directly from git history. I don't care as much about how far
>> back it should go. As far as knowing the package version (i.e. 1.2.3-6)
>> for each commit, that can easily be handled with a git hook.
>>
>> So, why bother putting similar information in two places when there are
>> better ways to go?
> 
> Thanks - I just won a small bet with myself as to when this thread would
> circle back to that discussion yet again...

I respectfully disagree with the assertion that the discussion is circular.
I might have been vague when I said "extract". What I meant was to
 - [have 'fedpkg build' automatically] create a changelog from the git
history
 - include that changelog in the rpm headers
 - the changelog is visible with 'rpm -q --changelog'.
Now both %changelog lovers and git lovers are happy campers.

Anyway, I see my argument will be going nowhere pretty soon.

Best wishes,
Alex


More information about the devel mailing list