https://bugzilla.redhat.com/show_bug.cgi?id=1957928 --- Comment #8 from David Cantrell <dcantrell@xxxxxxxxxx> --- (In reply to Neal Gompa from comment #5) > It was already asked before and rejected: > https://pagure.io/packaging-committee/pull-request/942 Yeah, I've read that. But there's still nothing in the packaging guidelines for Fedora that explicitly say "don't do this." I think you should understand the workflow that I'm using. I fail to see how %include is a problem here because the SRPM is built from the dist-git branch now and the spec file is processed accordingly. The resulting RPMs contain the changelog entries in the RPM headers, so all of the data is there. The resulting SRPM also includes the 'changelog' file which gets installed if you ever install the source RPM locally and rebuild the package. I see all of the comments in the PR you linked, but I have yet to see any actual problem from the workflow I have. Maybe I'm missing something. The packaging aspect of rpminspect and the data packages are downstream from the projects. I make a release upstream and then an RPM spec file style changelog block is generated. This is combined with any existing 'changelog' file in the downstream repo. I then have 'make koji' in the upstream project which builds that new release for each target release of Fedora and EPEL. I do this so the changelog that appears in the RPM spec is one-way from the upstream repo. I don't want to maintain a changelog in each Fedora and EPEL branch. Now since there are rebuilds and other people touching packages, my 'make koji' step sucks in whatever %changelog entries got added to the spec file and prepends them the existing changelog and then the new release's changelog lines are added on top of that. All of this is done so I can be out of the business of maintaining RPM style spec file changelogs but still provide that information to users. I'll change %setup and Source0 to use macros, but to be clear, these would never change without first making a new release upstream and running 'make koji'. The spec file is generated at release time. It doesn't matter to me though, I'll change it to the macros. I do all of the above to avoid "backcommitting" spec file changelogs to the upstream project. The entire desire I have is to not have a spec file changelog in two places. It's autogenerated from upstream and goes in the downstream repo, combined with whatever happened downstream independent of upstream work. I put together this workflow to provide information of substance in the RPM spec file changelog because people expressed interest in that (in fact, you specifically did, and your reasons for it made sense...I just wanted to make it not-a-manual-process). Prior to any of this, I just had a %changelog with a single link to the github project page history. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
