Bug 1088672 - Please move nm-openconnect-auth-dialog and the GNOME stuff (which depend on gtk3) to a subpackage
Summary: Please move nm-openconnect-auth-dialog and the GNOME stuff (which depend on g...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager-openconnect
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: David Woodhouse
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: depchain
TreeView+ depends on / blocked
 
Reported: 2014-04-17 01:27 UTC by Kevin Kofler
Modified: 2016-12-09 22:25 UTC (History)
5 users (show)

Fixed In Version: NetworkManager-openconnect-1.2.4-1.fc25
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-12-09 22:25:56 UTC
Type: Bug


Attachments (Terms of Use)

Description Kevin Kofler 2014-04-17 01:27:37 UTC
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.

Comment 1 David Woodhouse 2014-04-17 14:03:29 UTC
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 :)

Comment 2 David Woodhouse 2014-04-17 14:35:50 UTC
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.

Comment 3 Kevin Kofler 2014-04-17 14:44:31 UTC
> 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.

Comment 4 David Woodhouse 2014-04-17 16:24:09 UTC
(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...

Comment 5 Kevin Kofler 2014-04-17 16:30:54 UTC
> 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).

Comment 6 David Woodhouse 2014-07-08 16:31:22 UTC
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.

Comment 7 Jaroslav Reznik 2015-03-03 15:42:42 UTC
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

Comment 8 Fedora End Of Life 2016-07-19 20:28:52 UTC
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.

Comment 9 Rex Dieter 2016-07-20 11:18:54 UTC
rebasing to avoid autoclose

Comment 10 David Woodhouse 2016-07-21 08:35:29 UTC
We've actually just done this in master. Can you take a look and see if it meets your requirements? Thanks.

Comment 11 Kevin Kofler 2016-07-25 13:18:08 UTC
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.)

Comment 12 Fedora Update System 2016-12-05 12:02:35 UTC
NetworkManager-openconnect-1.2.4-1.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-4b0e78e336

Comment 13 Fedora Update System 2016-12-06 03:25:17 UTC
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

Comment 14 Fedora Update System 2016-12-09 22:25:56 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.