https://bugzilla.redhat.com/show_bug.cgi?id=2239566 Philipp Rudo <prudo@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |prudo@xxxxxxxxxx --- Comment #4 from Philipp Rudo <prudo@xxxxxxxxxx> --- Hi Carl, thanks for the thorough review. It's very much appreciated! Please find a my questions/comments below. (In reply to Carl George 🤠 from comment #2) [...] > ============================================================================= > === > > There is no URL tag, resulting in an rpmlint warning. On a related note, > there are quite a few source files in this package. Would it be possible to > establish an upstream repository somewhere like GitHub or GitLab that can be > used to obtain tarballs of the source files? That upstream could also > determine the versions. Right now it's not clear where the version of > 1.0.42 is coming from. No other file in the SRPM besides the spec file has > that string. I see your point and agree that having an upstream repo would be beneficial. But in my opinion splitting the current rpm is already a pretty big task. That's why I would prefer to do the change in a subsequent step after the split has been completed. [...] > ============================================================================= > === > > rpmlint is also reporting an error that this architecture-specific package > does not contain any architecture-specific binaries. Should it be marked as > noarch? Ok, that's one area where I'm not entirely sure. Thing is that while we don't ship arch-specific binaries we do ship arch-specific udev rules and dracut modules. In addition there are some arch-specific dependencies. My problem is that I don't know exactly when those arch-specific parts in the spec file are evaluated. In case that is done during build time I'm afraid we need to stick with the arch-specific rpms. If not we should mark it as noarch. [...] > ============================================================================= > === > > I noticed there are systemd service files and a target file installed to > /usr/lib/dracut/modules.d/99kdumpbase. Should those be installed to the > regular systemd directories, or do they need to be here? Those need to stay here. Reason is that those services are only needed in the initrd that contain the kdump module. But those initrds are special purpose and cannot be used for a "normal" boot. In fact those services won't even start after a "normal" boot. > ============================================================================= > === [...] Thanks Philipp -- 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 https://bugzilla.redhat.com/show_bug.cgi?id=2239566 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202239566%23c4 -- _______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
