https://bugzilla.redhat.com/show_bug.cgi?id=1957928 David Cantrell <dcantrell@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(ngompa13@xxxxxxxx | |m) --- Comment #10 from David Cantrell <dcantrell@xxxxxxxxxx> --- (In reply to Neal Gompa from comment #9) > (In reply to David Cantrell from comment #8) > > (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. > > > > This really sounds like you should just have an upstream changelog file that > gets pulled in as a doc. The point of the %changelog in the package is to > detail the packaging changes. I know people do mix the two, but the > fundamental assumption for RPM changelogs that most people have is that they > detail the changes done to the package, and the changes to the software is > inside the package as a file. OK, so I've heard arguments in both directions here. The %changelog should include packaging changes, but it should also include summaries of changes of significance. I can see arguments for both. In the case of these rpminspect packages, nothing of consequence is going to really happen packaging wise. They are all very simple. Are you saying the %changelog can just simply be "- Upgrade to rpminspect-data-centos-1.0" and leave it at that? I can add a %doc which is a generated ChangeLog from the git log. A comparison can be made with anaconda where we have always maintained the RPM %changelog detailing all of the changes for each release. I felt that same idea applied here. At least in the case of the rpminspect data packages, maybe not necessarily the program. What would you prefer I do for the %changelog here? Maybe I am overcomplicating things because I felt people wanted to see the detailed changes via "rpm -q --changelog PACKAGE". > The problem I generally have with your method of changelogs is the usage of > %include, which just makes it messy, but it's included as a source, so... > > *sigh* I get that and I don't want to make things confusing for people. My issue is I'm trying to understand the technical failures by using %include. Style opinions vary across all developers, so I get that. You and I can just disagree on style, which is fine. The failure I have been able to reproduce using %include is if you are rebuilding locally where _topdir gets redefined in your environment and rpmbuild then cannot find the changelog to include. It won't fail, it just won't include the changelog. But the default install of rpm, the use of rpmdev-setuptree for local development, and the use of fedpkg using dist-git all result in the desired output. fedpkg local can be messed up, so I assume that's a reasonable failure to avoid. I am reworking how I generate this package and will post an update later today. Once I get things sorted out with this one, I will propagate the changes over to the other rpminspect packages for consistency. -- 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
