https://bugzilla.redhat.com/show_bug.cgi?id=1686506 --- Comment #20 from Joe Doss <joe@xxxxxxxxxxxxxx> --- (In reply to Robert-André Mauchin from comment #18) > I would not mind some help but currently Joe Doss is not a member of the > Packager group and would need to be sponsored. He, if he'd like to do so, > would need to grok the Packaging Guidelines. Currently some minor issues in > his COPR package make it not pass the Guidelines. (Group: not to be used, > %defattr(-,root,root,-) %attr(0755, root, root) %clean neither, lack of the > macros to use parallel building, lack of SystemD macros) Getting sponsored shouldn't be an issue. I have been putting it off for some time now as I was actually going to use wireguard-tools as the package to get me sponsored. As for the Packaging Guidlines I am well aware of them. I have been putting off cleaning up the jdoss/wireguard wireguard-tools spec file to meet the guidelines until I was ready to get this package into Fedora when WireGuard went into the mainline kernel. You just beat me too it. :) > (In reply to Joe Doss from comment #17) > > Your response doesn't really address my questions, so let me rephrase: > > > > We should make the needed changes between these two packages so we have some > > sort of path to migrate people to the Fedora package instead of using the > > one in copr. There are a ton of people using my repo and I want to make sure > > they have a good experience moving over to this package if this makes it > > into Fedora. If there are specific changes that need to happen to my spec, I > > am willing to do so in order to move them off of the wireguard-tools in the > > copr repo. What changes are needed to ensure end users are taken care of > > here? > > > There's two main problems I'm not sure how to solve: > > - your package uses DKMS and requires the DKMS package. Fedora don't accept > DKMS. Kmods are relegated to RPMFusion. I am aware of this Fedora policy. I am simply talking about the wireguard-tools package. We are going to have to maintain the wireguard-dkms and wireguard-tools package in copr for the foreseeable future for older versions of CentOS and RHEL. I can modify my spec to match with yours which should make it easier to maintain for both userbases. > In providing wireguard-tools in Fedora, before mainlining I plan to soft > depend on the kmod from RPMFusion. People upgrading from your COPR to Fedora > would need to remove the DKMS and activate RPMFusion to install the kmod. I > don't know how many of your users don't have also RPMFusion activated. > After mainlining, I drop the soft depend. After that point your users would > probably need to remove the DKMS anyway. We shouldn't make switching to the kmod from RPMFusion a requirement, soft or hard, here at all. Having to enable RPMFusion just for WireGuard is overkill. That's why I created the copr repo from the start. It's just WireGuard nothing more. If users are fine with using DKMS until WireGuard goes into mainline, we should just let them stick with it until that time comes and not force the choice on them. Can we make a soft require for the kmod or wireguard-dkms here? I would argue that not having any depends makes the upgrade easier on everyone. It is less than ideal to have to install any third party repo to install a Fedora package because of an enforced soft/hard requirement. Maybe it is just better to wait until WireGuard goes into the mainline kernel and Fedora picks it up so we don't need to make any choices here? > Or you push an update that de-install itself and remove your COPR in a > post-upgrade script? I have no idea if this is feasible or how. I wouldn't want to make that kind of choice for a user in an RPM. We should work with Upstream WireGuard to communicate to the Fedora endusers when the time to make these changes comes. > > Also, to be more to the point. Upstream very much enjoys the swiftness of > > new package bumps and thorough testing, when they're making new releases. > > Are you available to do these as diligently and quickly as the large > > userbase has grown to expect? If not, do you want help? I have maintained > > this my copr repo as the official Fedora for the WireGuard project since > > 2016 and I am thrilled that someone else has taken the time to push it into > > Fedora proper. I don't mind continuing to do so if you want to collaborate > > on it together. > > I keep up daily except for January: > https://pkgs.rpmfusion.org/cgit/free/wireguard.git/ > I follow the ML so I get the release on the day or morning after. Of course > more eyes and maintainers are always appreciated. Sounds good. I will get my Packager status sorted out and we can figure out the best path for this stuff together. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx
