https://bugzilla.redhat.com/show_bug.cgi?id=1957928 Neal Gompa <ngompa13@xxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(ngompa13@xxxxxxxx | |m) | --- Comment #11 from Neal Gompa <ngompa13@xxxxxxxxx> --- (In reply to David Cantrell from comment #10) > (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". > I think that as long as nobody is specifically asking for it, I wouldn't do it that way. As far as I know, the reason Anaconda does that is that it's part of the tito-based workflow they adopted. If you *want* to, then by all means, but the general guidance I've gotten over the years is that having the software changelog in the docdir is more than sufficient for those kinds of changes. > > 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. It's basically the topdir thing that's a problem. Otherwise, *shrug*... -- 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
