Description of problem: NetworkManager-openconnect depends on gtk3 for the nm-openconnect-auth-dialog. This drags in gtk3 as a dependency of kde-plasma-nm-openconnect. NetworkManager-openconnect is also missing the -gnome subpackage that the other VPN plugins have for the GNOME-specific items, which also drag in gtk3. kde-plasma-nm-openconnect has its own authentication dialog and does not need the GTK+ one. Version-Release number of selected component (if applicable): NetworkManager-openconnect-0.9.8.4-2.fc21 How reproducible: Always. Steps to Reproduce: 1. Install kde-plasma-nm-openconnect on a system without gtk3. Actual results: gtk3 is required. Expected results: gtk3 is not required. Additional info: All the NetworkManager VPN plugins have this packaging issue, I am filing a separate bug for each.
Just got in from the US; thinking is at a premium. How exactly do you want this done, and what needs to change in comps to match, and ensure that the right bits are pulled in for the GNOME installations? Let's make sure we do this consistently across the VPN packages that need to change. Feel free to express the answer in 'diff -up' form. Or just commit it :)
I have committed, but not built, a version with the -gnome subpackage split out but with NetworkManager-openconnect depending on NetworkManager-openconnect-gnome rather than vice versa. I'll let you deal with the dependencies/comps issues coherently across the VPN packages, which should now be fairly trivial.
> but with NetworkManager-openconnect depending on > NetworkManager-openconnect-gnome rather than vice versa That won't solve the dependency issue, because now the dependency chain is kde-plasma-nm-openconnect → NetworkManager-openconnect → NetworkManager-openconnect-gnome. What the other VPN packages have done for the -gnome subpackage is to use versioned Obsoletes (NetworkManager-openconnect-gnome Obsoletes: NetworkManager-openconnect < the EVR where the split was introduced) to drag in -gnome on existing installs. Then there's also the issue of the auth-dialog dragging in gtk3 and libgnome-keyring, which is also present in the other VPN plugins. Maybe the safest solution for that is to put the non-UI parts into a NetworkManager-openconnect-core or NetworkManager-openconnect-service or such subpackage, then we can change kde-plasma-nm-openconnect to depend on that, and people just installing NetworkManager-openconnect still get the GTK+ support by default. Alternatively, the same versioned Obsoletes trick could be used to split out a NetworkManager-openconnect-gtk, but then users of the NetworkManager-gnome nm-applet will have to install -gtk rather than just the main package.
(In reply to Kevin Kofler from comment #3) > > but with NetworkManager-openconnect depending on > > NetworkManager-openconnect-gnome rather than vice versa > > That won't solve the dependency issue, because now the dependency chain is... Yes, I understand that. > Then there's also the issue of the auth-dialog dragging in gtk3 and > libgnome-keyring, which is also present in the other VPN plugins. What do you mean, "also"? The auth-dialog is the part that needs to be moved out into the -gnome subpackage, surely? That isn't "also"; that's a restatement of the original problem...? > Maybe the safest solution for that is to put the non-UI parts into a > NetworkManager-openconnect-core or NetworkManager-openconnect-service or > such subpackage, then we can change kde-plasma-nm-openconnect to depend on > that, and people just installing NetworkManager-openconnect still get the > GTK+ support by default. Alternatively, the same versioned Obsoletes trick > could be used to split out a NetworkManager-openconnect-gtk, but then users > of the NetworkManager-gnome nm-applet will have to install -gtk rather than > just the main package. Hm, why not NM-openconnect and NM-openconnect-gnome? Either way, sort this out and have a consistent plan across VPN plugins, and let me know what it is (or just commit it). Don't leave the details for every VPN plugin owner to invent differently...
> What do you mean, "also"? The auth-dialog is the part that needs to be moved > out into the -gnome subpackage, surely? That isn't "also"; that's a restatement > of the original problem...? If you look at how the other packages are split, they have only the gnome-shell-specific stuff in -gnome, the auth-dialog is in the main package. And yes, that's the issue. Moving the auth-dialog into the -gnome package would fix it for us (KDE), but I'm not sure what the other GTK+-based desktops think of that idea. That's why I proposed a solution with 3 packages (one non-GUI, one with the GTK+ auth-dialog for the standalone nm-applet (the one in "NetworkManager-gnome", which confusingly is no longer used in GNOME itself) and one with the gnome-shell stuff).
That appears to make sense. But again, let's make sure we have a coherent answr which is being applied consistently across the other VPN packages. And if we're doing it differently to Debian and other distributions which already split these packages, it would be good to be sure we have a *reason* for being different. When you have a solution, feel free to commit it.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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.
rebasing to avoid autoclose
We've actually just done this in master. Can you take a look and see if it meets your requirements? Thanks.
Looks right. Now we just need somebody to test with plasma-nm to confirm that the split package works fine with it. (It should: plasma-nm has its own VPN UIs.)
NetworkManager-openconnect-1.2.4-1.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-4b0e78e336
NetworkManager-openconnect-1.2.4-1.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-4b0e78e336
NetworkManager-openconnect-1.2.4-1.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.