Well, one big advantage from the %include/%changelog way would be the possible 
opt-in. If you want to automate "slapping the changelog itself at the tail of 
the spec", then it means you have to actually change the build infrastructure 
to do it.

TBH the biggest issue I see currently is that the SRPM changelog duplicates the 
.spec changelog. And these two might be possibly different. This should not 

If I am thinking about the workflow how to obtain the log from SCM and get it 
into SRPM, I think that the "rpmbuild -bs" could call some macro to update the 
changelog. But at that moment, you probably don't want to modify the .spec file 
which as about to be packaged into SRPM. Modifying some changelog file would be 
more acceptable IMO.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Rpm-maint mailing list

Reply via email to