https://bugzilla.redhat.com/show_bug.cgi?id=1686506
--- Comment #22 from Robert-André Mauchin <zebob.m(a)gmail.com> ---
Spec URL:
https://eclipseo.fedorapeople.org/wireguard-tools.spec
SRPM URL:
https://eclipseo.fedorapeople.org/wireguard-tools-0.0.20190227-2.fc31.src...
(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