https://bugzilla.redhat.com/show_bug.cgi?id=1686506 --- Comment #18 from Robert-André Mauchin <zebob.m@xxxxxxxxx> --- (In reply to Jason A. Donenfeld from comment #16) > > - or keeping wireguard as a meta package > > If you'd like to have a "wireguard" meta package, *in addition to the > wireguard-tools package*, that's totally fine with me. There might indeed at > some point be other things that get included in there. kmod(wireguard.ko) > seems like it'd make sense, for example. > I'll see what I can do. > > > > From Joe: > > You beat me to it. If you want someone to help co-maintain this package, please let me know. > > I'd actually strongly recommend adding Joe as a co-maintainer. He > understands the project extremely well, has been with us packaging it from > the beginning, and is pretty much an ideal maintainer. We've got a good > working relationship, so as weird quirks upstream come up, I'm pretty > confident Joe can roll with doing the right thing on the packaging side. 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) (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. 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. - the Epoch thing: this prevents any transition from your COPR to the Fedora package. I don't want to set an Epoch: 2 on a new package. I don't know if removing it from your end would do something? If you remove your Epoch a dnf update would not pick up the new package because it would be considered lower than the current one. AFAIK only a distro-sync could bypass that I think but I don't see how you could communicate with all your users to tell them to do a distro-sync. And if you could, best would be to tell them to remove the package, deactivate your COPR, and install the one from Fedora. See the conundrum? I'm open to suggestions on how to proceed. 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. > 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. -- 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
