https://bugzilla.redhat.com/show_bug.cgi?id=1957928 David Cantrell <dcantrell@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bcl@xxxxxxxxxx Flags| |needinfo?(bcl@xxxxxxxxxx) --- Comment #12 from David Cantrell <dcantrell@xxxxxxxxxx> --- To close the loop on this... (In reply to Neal Gompa from comment #11) > (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. That's not the reason anaconda uses the RPM %changelog that way. They may not do this anymore. I started working on anaconda in 2005 and the unique thing about the releases is that there was no upstream tarball release of anaconda. A release was made in SRPM format and built in Fedora directly. We used the %changelog block as our project's changelog. This is different than many other projects, but it's what was going on when I joined the project. Having worked on anaconda for so long, I began to like the summarized %changelog entries that reflected changes that actually went in to the code as opposed to spec file changes or other such stuff like that. I have not looked so I don't know if the anaconda team still does that, but at least that's the reason we were doing that for so long. > > > 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*... Ehhhh, ok. I mean, I kind of consider that a featureful flaw of rpmbuild anyway. If you go mucking around with topdir, you're bound to hit some problems and my personal view is if you're doing that and it breaks, you get to keep the pieces. The only thing I've been able to reproduce is not getting a %changelog, which isn't fatal for RPM. All that aside, I have reworked how I am automating builds for Copr and released builds in Koji so it's no longer generating a changelog like I had been. It now generates a single "- Upgrade to NAME-VER" entry and prepends that to whatever it finds in the downstream git repo for the package. The combined changelog block is committed downstream so the growing changelogs are not pushed back upstream but just live on in their respective branches in package git. To me this gets to what you were suggesting while also retaining any changelog modifications that appear downstream *and* not having to keep spec files in sync in two locations. New spec file and SRPM posted: Spec: https://dcantrell.fedorapeople.org/rpminspect-data-centos.spec SRPM: https://dcantrell.fedorapeople.org/rpminspect-data-centos-1.0-1.fc34.src.rpm I know the package already has review+, but I wanted to make this change before getting it in to the distribution. If this is satisfactory for all parties who have commented, I will go forth with it. I will also make these changelog adjustments for the existing rpminspect-data-fedora package as well. -- 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
