Bug 1686506

*** Bug 1686022 has been marked as a duplicate of this bug. ***

Thanks, this looks fairly good.

A couple of questions:

1.) Why do you call the package lowercase "wireguard"? Upstream seems to call the thing "WireGuard"

2.) What's the use of this in Fedora?

> Provides:       %{name}-kmod-common = %{version}
> %if 0%{?fedora} || 0%{?rhel} > 7
> Suggests:       %{name}-kmod >= %{version}
> %endif

The Fedora kernel-core package seems to provide "kmod(<module>.ko)" for the modules it ships. I guess that "kmod(wireguard.ko)" is what we should depend on? Though I suppose only a weak dependency would do until the kernel actually ships the module.

(In reply to Lubomir Rintel from comment #2)
> 1.) Why do you call the package lowercase "wireguard"? Upstream seems to
> call the thing "WireGuard"

>In Fedora packaging, the maintainer uses their best judgement when considering how to name the package. While case sensitivity is not a mandatory requirement, case SHOULD only be used where necessary. Keep in mind to respect the wishes of the upstream maintainers. If they refer to their application as "ORBit", you SHOULD use "ORBit" as the package name, and not "orbit". However, if they do not express any preference of case, you SHOULD default to lowercase naming.
https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#_case_sensitivity

In any all the other distros use lowercase.


> 
> 2.) What's the use of this in Fedora?
> 
> > Provides:       %{name}-kmod-common = %{version}
> > %if 0%{?fedora} || 0%{?rhel} > 7
> > Suggests:       %{name}-kmod >= %{version}
> > %endif
> 
> The Fedora kernel-core package seems to provide "kmod(<module>.ko)" for the
> modules it ships. I guess that "kmod(wireguard.ko)" is what we should depend
> on? Though I suppose only a weak dependency would do until the kernel
> actually ships the module.

For now it' for compatibility with the module from RPMFusion. Once the module is in mainline, it would be removed. Apparently this won't happen until at least 5.2.

> # Use standard perms for /etc/wireguard
> sed -i 's|install -v -m 0700|install -v -m 0755|' src/tools/Makefile

Are you sure this is a good idea? I'm pretty sure that this contains the interface configuration, and may be considered sensitive information.

I'm not sure, it shows up as an error en Fedora-review.


Spec URL: https://eclipseo.fedorapeople.org/wireguard.spec
SRPM URL: https://eclipseo.fedorapeople.org/wireguard-0.0.20190227-2.fc31.src.rpm

Somebody asked me to chime in here about naming. The WireGuard project has long had an "official" set of packages maintained by jdoss on copr, and the usage there is fairly high. I think it'd be prudent to stick with the existing package names. You can see how it boils down by distro here: https://www.wireguard.com/install/

Packages that install the tools (wg, wg-quick, man pages, etc) should be called "wireguard-tools".

Packages that install a dkms module should be called "wireguard-dkms".

Packages that install a binary module should be called "wireguard-kmod".

Packages that install all of the above or pull in multiple as dependencies or are otherwise some sort of meta-package should be called "wireguard".

(In reply to Jason A. Donenfeld from comment #6)
> Somebody asked me to chime in here about naming. The WireGuard project has
> long had an "official" set of packages maintained by jdoss on copr, and the
> usage there is fairly high. I think it'd be prudent to stick with the
> existing package names. You can see how it boils down by distro here:
> https://www.wireguard.com/install/
> 
> Packages that install the tools (wg, wg-quick, man pages, etc) should be
> called "wireguard-tools".
> 
> Packages that install a dkms module should be called "wireguard-dkms".
> 
> Packages that install a binary module should be called "wireguard-kmod".
> 
> Packages that install all of the above or pull in multiple as dependencies
> or are otherwise some sort of meta-package should be called "wireguard".

We already had this discussion over at RPMFusion and it had then be decided to drop the "tools" suffix: https://bugzilla.rpmfusion.org/show_bug.cgi?id=5020#c2

It's unfortunate you had that misguided discussion without the input of upstream. I disagree with the conclusion there of WireGuard being merely, "a piece of software, which just happens to require a kernel module in order to operate." We rather expect that many different types of software will be formed from the small basic building block of a WireGuard tunnel.

The name of the tools is wireguard-tools. As soon as WireGuard is upstreamed, the name of the repo will be wireguard-tools. The tarballs of that software will be called wireguard-tools-1.0.tar.xz. Extremely common nomenclature for tools that operate particular network interface types is -tools.

So I urge you to both stick with the naming conventions used by both numerous upstream kernel networking projects and by the WireGuard project itself.

> It's unfortunate you had that misguided discussion without the input of upstream.

This is an unfair thing to say. The name chosen follows to the upstream's choice of the repository name and the tarballs.

In any case, thanks for your input. I'd like to point out that 1.) we strive to follow upstream preference and 2.) RPM Fusion discussion, while it can provide a good input, is not anything we need to follow.

The upstream decision is to go with the -tools suffix; we should call this wireguard-tools. I'm fine with compatibility provides/obsoletes if you care about RPM Fusion migration path (I don't).

> The upstream decision is to go with the -tools suffix; we should call this wireguard-tools.

Great, thanks.

I'm hesitating between either:

 - renaming to wireguard-tools
 - or keeping wireguard as a meta package and adding -tools as a subpackage

The meta would Requires tools and Recommends the kmod until it is in mainline.

I'd like input from you's (Neal, Lubomir) regarding the best course of action.

(In reply to Robert-André Mauchin from comment #11)
> I'm hesitating between either:
> 
>  - renaming to wireguard-tools
>  - or keeping wireguard as a meta package and adding -tools as a subpackage
> 
> The meta would Requires tools and Recommends the kmod until it is in
> mainline.
> 
> I'd like input from you's (Neal, Lubomir) regarding the best course of
> action.

I'd go for renaming the package to wireguard-tools. It's clearly what upstream wants.

We can do "Recommends: kmod(wireguard.ko)" until it is mainlined, which will hopefully be soon.

@Jason, has there been any progress on getting WireGuard mainlined?

Spec URL: https://eclipseo.fedorapeople.org/wireguard-tools.spec
SRPM URL: https://eclipseo.fedorapeople.org/wireguard-tools-0.0.20190227-2.fc31.src.rpm

@Robert-André Mauchin thanks for pushing this forward. You beat me to it. If you want someone to help co-maintain this package, please let me know. 

Also, how will this package handle users that have installed wireguard-tools from my copr repo? Is there something we can do either in this spec file or in mine that would ensure that we don't have any conflicts between the two? I rather not have users get any errors when this goes upstream into Fedora.

The problem with your package is that it set Epoch: to 1 so it will always be picked up over the Fedora package.

> - 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.

> We can do "Recommends: kmod(wireguard.ko)" until it is mainlined, which will hopefully be soon.

> @Jason, has there been any progress on getting WireGuard mainlined?

Yes, working on it!



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.

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?

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.

(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.

Tibbs on IRC set me this guideline:


Epochs from Third Party Repositories

If a package to be imported is or previously was present in a publicly accessible repository, the packager can optionally include an Epoch tag equal to that of the most recent version of the third-party package.

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_epochs_from_third_party_repositories

So Epoch it is. Still need to tell your users to use RPMFusion somehow. It would be nice to test if the DKMS is automatically removed to.

(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.

(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

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.

> I have the ability to sponsor him myself if he'd like when the package is finalized.

Is there any reason for this order of operations? Can we get Joe sponsored and ready to serve as soon as possible rather than waiting for the completion of something he's already involved in? He's played an integral part of WireGuard on Fedora thus far, so it seems like a good thing to keep him in the game moving.

(In reply to Jason A. Donenfeld from comment #23)
> > I have the ability to sponsor him myself if he'd like when the package is finalized.
> 
> Is there any reason for this order of operations?

Not really. Other than there's not much he can do until the package is actually imported.

> (In reply to Joe Doss from comment #20)
> > (In reply to Robert-André Mauchin from comment #18)
...
> > 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.

Sorry if I made that impression. I merely wanted the bits in, totally oblivious to anyone's third party packages or possible problems with them.

I'm not in a hurry. I'm glad that you two got in touch regarding eventually adding this to Fedora. I'm totally fine if the bits are imported to Fedora only after WireGuard is mainlined. If anything, we'll have plenty of time to iron out the wrinkles by then. That said, I will not delay my approval when the package passes review -- I fully count on you to import the package at appropriate time.

Also, I suppose Joe's packager status can be sorted by then as well.

---

My $0.02 about the RPM Fusion and COPR migrations: we should not bend backwards to make up for things broken outside Fedora. The COPR users are warned that COPR packages are unofficial and "quality may vary". When things break, which is what tends to happen when packages escape quality control or coordination, the users should be expected to keep both parts.

That said, I'm not going to object bits that would be there to ease the upgrade pain, if they're not totally unreasonable. An Epoch:, or Provides:/Obsoletes: would be fine.

Now back to the usual review business.

(In reply to Robert-André Mauchin from comment #22)
> Spec URL: https://eclipseo.fedorapeople.org/wireguard-tools.spec
> SRPM URL:
> https://eclipseo.fedorapeople.org/wireguard-tools-0.0.20190227-2.fc31.src.rpm

1.) Please don't add this package:

> %package -n wireguard
> Summary:        Metapackage providing the WireGuard tools and the WireGuard kernel module

It does not make any sense in Fedora context.

If you intend to cope with the kmod mess either add the metapackage to the same repository where the kmod lives or just bring back the weak dependency.

Other than that the package looks good to me.

Thank you!

(In reply to Lubomir Rintel from comment #24)
> My $0.02 about the RPM Fusion and COPR migrations: we should not bend
> backwards to make up for things broken outside Fedora. The COPR users are
> warned that COPR packages are unofficial and "quality may vary". When things
> break, which is what tends to happen when packages escape quality control or
> coordination, the users should be expected to keep both parts.

My inbox and the #wireguard IRC channel respectfully disagrees here. The Copr package is the official way for users to install WireGuard on Fedora because Fedora doesn't allow DKMS packages. It was chosen for us to bring WireGuard to Fedora users as easily as possible. From my perspective we cannot throw our hands up and say well they are on their own here because they are on Copr. If we can reasonably make the transition as pain free as possible, it should top priority for this official Fedora package to help get people moved over as that is a better experience for the user base. I am willing to make whatever changes to my Copr repo to help ease any concerns that you have so we are not bending backwards too much. 

 
> (In reply to Robert-André Mauchin from comment #22)
> > Spec URL: https://eclipseo.fedorapeople.org/wireguard-tools.spec
> > SRPM URL:
> > https://eclipseo.fedorapeople.org/wireguard-tools-0.0.20190227-2.fc31.src.rpm
> 
> 1.) Please don't add this package:
> 
> > %package -n wireguard
> > Summary:        Metapackage providing the WireGuard tools and the WireGuard kernel module
> 
> It does not make any sense in Fedora context.
> 
> If you intend to cope with the kmod mess either add the metapackage to the
> same repository where the kmod lives or just bring back the weak dependency.

I agree. This should be a stand alone wireguard-tools package in Fedora and should not be a metapackage that is trying to dictate a particular install method as a requirement. Kmods and DKMS both have their warts and I don't want to inflict pain on anyone that hasn't accepted their fate with their chosen install method.

There seems to be a lot of disconnect here. Essentially, Joe's been working on WireGuard on Fedora/RHEL for a really long time and has been intimately involved with packaging for the process. He knows enormous amounts about upstream development. Meanwhile eager Fedora packagers have come along, which is great and encouraging, and there's certainly an opportunity here. But clearly the approach and the attitude is pretty out of sync with the expectations of both our tens of thousands of users and of upstream. And the current direction is not sounding very appealing from a packaging direction as well.

I'd encourage this approach: close this bug, get Joe started on official Fedora packaging induction, and when things are ready to go, Joe will open a new bug report with the package he intends to add. At that time if the OP's of this bug are interested in helping him out with the package, Joe can use his judgement.

(In reply to Jason A. Donenfeld from comment #26)
Please let's keep this focused on getting the package reviewed to comply with the packaging guidelines.
(I reached to Jason privately to discuss the disconnect. It seems to me we're aligned now; we'll get the package reviewed here, and Robert & Joe will coordinate the package maintenance further on.)

(In reply to Jason A. Donenfeld from comment #26)
> There seems to be a lot of disconnect here. Essentially, Joe's been working
> on WireGuard on Fedora/RHEL for a really long time and has been intimately
> involved with packaging for the process. He knows enormous amounts about
> upstream development. Meanwhile eager Fedora packagers have come along,
> which is great and encouraging, and there's certainly an opportunity here.
> But clearly the approach and the attitude is pretty out of sync with the
> expectations of both our tens of thousands of users and of upstream. And the
> current direction is not sounding very appealing from a packaging direction
> as well.
> 
> I'd encourage this approach: close this bug, get Joe started on official
> Fedora packaging induction, and when things are ready to go, Joe will open a
> new bug report with the package he intends to add. At that time if the OP's
> of this bug are interested in helping him out with the package, Joe can use
> his judgement.

No worry, I'll see to guide Joe Doss through the sponsorship process as soon as I have the time. He'll be comaintainer once the package is reviewed.

Congrats on patch v9, I hope it will make it into 5.2.

Apparently I've been reviewing this from this packager even though this already exists... Closing this in favor of that one.

*** This bug has been marked as a duplicate of bug 1787714 ***