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
happen.
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:
https://github.com/rpm-software-management/rpm/issues/393#issuecomment-365207843
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
