Created attachment 733443 [details] Patch to fix spec file Description of problem: NetworkManager-openconnect spec file does not conform to many Fedora Packaging guidelines Version-Release number of selected component (if applicable): How reproducible: Look at spec file Steps to Reproduce: 1. Includes for instance '%define' instead of '%global' and more Actual results: I'm providing a patch which brings NetworkManager-openconnect.spec to a better state and also splits it into NetworkManager-openconnect and NetworkManager-openconnect-gnome Expected results: Additional info: I've gone through the process of changing NetworkManager-ssh.spec (based on NetworkManager-openvpn.spec) to conform with Fedora packaging standards and decided it'll be a good idea to implement these changes for the rest of the NetworkManager-* VPN plugins out there.
Created attachment 734158 [details] Patch to fix spec file
Note about patch: Contains a deliberate error (TODO) and needs to be replaced with latest known version, because of the package split. As Dan (Williams) mentioned, it is mandatory for updates to work correctly.
what is the point of splitting out a -gnome package? The base package depends on gnome just as much as the -gnome package here does
As implemented, it does. But perhaps the auth-dialog wants to live in the GNOME package too?
It seems to me that if NetworkManager-openconnect can't be used without NetworkManager-openconnect-gnome, then there's no point in splitting out NetworkManager-openconnect-gnome at this time.
It can, though. kde-plasma-networkmanagement works with it.
If kde-plasma-networkmanagement has an equivalent of /usr/libexec/nm-openconnect-auth-dialog then I guess splitting out a -gnome package makes sense.
It isn't a separately invoked executable in the KDE world; it's a library plugin for kde-plasma-networkmanagement and it all runs in the context of kded. But yes, it's there in the kde-plasma-networkmanagement-openconnect package. Ubuntu splits out the -gnome packages separately; I'm guessing that's where this comes from? Let's do it consistently for all VPN plugins if we do it for OpenConnect though. I assume the reporter is doing so? I don't know how we handle the task of ensuring that the appropriate UI package is installed for the appropriate VPN(s) and the appropriate desktop environment(s). On the UI side, automatic installation of these things on demand would be good...
I'm happy we have a discussion about it. Although as Dan (Winship) suggested for most packages it doesn't really matter just yet, as the NetworkManager-XXX package will depend on gnome, because of auth-dialog. I posted this bug + patch as a future change, after we implement a separation for auth-dialog for gnome and for text (or whatever). Generally speaking it'll be good to have the package separation going early, even if it is a bit misleading. But that's for the maintainer to decide (Dan Williams). My recently featured NetworkManager-ssh doesn't depend on gnome as the auth-dialog doesn't use any gnome packages. Other plugins do (like this one, the openconnect one). In addition to that change the patch features other changes to the spec which brings it a better "fedora-review state", so if the package separation will not happen, the patch still features other things I believe we'd like to see in the spec. The package separation can happen later, for sure.
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle. Changing version to '20'. More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20
Leaving aside the split which is discussed in bug 1088672, please could I have a version of the patch which just fixes the other issues? Note that adding 'BuildRequires: gtk3-devel' is also not in line with Fedora packaging guidelines; that should be 'BuildRequires: pkgconfig(gtk+-3.0)'
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.