https://bugzilla.redhat.com/show_bug.cgi?id=1686506 --- Comment #22 from Robert-André Mauchin <zebob.m@xxxxxxxxx> --- Spec URL: https://eclipseo.fedorapeople.org/wireguard-tools.spec SRPM URL: https://eclipseo.fedorapeople.org/wireguard-tools-0.0.20190227-2.fc31.src.rpm (In reply to Joe Doss from comment #20) > (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. > I intend to provide this for EPEL7 too. > > 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. > We could add a boolean dependency but that won't work for RHEL/EPEL/CentOS. > 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? > That's what I intended to do initially. But it seems Lubomir wants it in early? It would be easier otherwise. > > 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. (In reply to Dusty Mabe from comment #21) > (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. > > > Once this package is past review we can get him added to the packager group > pretty easy. > Robert-André you'll need to open a ticket against the packager sponsors > pagure instance [1] > stating that you are a package owner who would jdoss to co-maintain your > package. Then he > will get sponsored as a packer. This was pulled from [2]. > > > [1] https://pagure.io/packager-sponsors/ > [2] > https://fedoraproject.org/wiki/ > How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer I have the ability to sponsor him myself if he'd like when the package is finalized. -- 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
