Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#63777 - [netctl] move wifi-menu in a separate package

Attached to Project: Arch Linux
Opened by Muflone (muflone) - Sunday, 15 September 2019, 14:44 GMT
Last edited by Doug Newgard (Scimmia) - Monday, 16 September 2019, 00:27 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

Partially related to https://bugs.archlinux.org/task/39056

The wifi-menu program in the netctl package is not usable until you install some needed extra optional dependencies like dialog and wpa_supplicant.

Such organization of the package is not useful at all and renders wifi-menu unusable as when launched it will claim to install dialog and wpa_supplicant packages in order to run.
There are no command line arguments to use wifi-menu without dialog and wpa_supplicant, in other words there's not a single point to have an installed wifi-menu without dialog and wpa_supplicant packages.

Please consider moving out wifi-menu program in a separated optional package (netctl-wifi or wifi-menu package) and keep hard dependencies on dialog and wpa_supplicant on the new package.

At the actual state the netctl package will appear broken, as it will be unable to accomplish a most common of his uses until you install the dependencies listed as optional.
Splitting the package we'll have a proper working netctl package without the need to have wpa_supplicant for ethernet users and an optional netctl-wifi package which fully works when installed, as it will automatically get its dependencies to run, for wifi networks users.


Additional info:
* netctl 1.20-1


Steps to reproduce:
1. install a standard Arch Linux with
2. install netctl package
3. run wifi-menu
4. the program will not launch, asking to install dialog and wpa_supplicant dependencies
This task depends upon

Closed by  Doug Newgard (Scimmia)
Monday, 16 September 2019, 00:27 GMT
Reason for closing:  Duplicate
Additional comments about closing:   FS#39056 
Comment by Doug Newgard (Scimmia) - Sunday, 15 September 2019, 16:08 GMT
This configuration is completely and totally normal in Arch. How is this package any different?
Comment by Muflone (muflone) - Sunday, 15 September 2019, 21:20 GMT
This is a proposed change to have a fully working wifi-menu and to avoid to distribute an unusable program into a core package
1) unuseful for a wired network user
2) unusable for a wireless network user
Comment by Eli Schwartz (eschwartz) - Sunday, 15 September 2019, 22:33 GMT
How is it an unusable program? Reportedly, many users use netctl with profiles, which does not require wifi-menu/dialog, and also, many partially overlapping users use netctl to manage wired connections.

Manifestly, the primary purpose of the "netctl" package is to provide the "netctl" command.

*soapbox*
The disturbing popularity of wifi-menu is a sign of nothing other than that we should in fact be mandating the use of nmtui, which uses networkmanager to handle all these use cases and also do it in a manner I consider to be proper. Let's drop netctl from core and move networkmanager there instead.

*step off soapbox*
But no, really, why do you assume that netctl is fundamentally "unusable" just because the non-core functionality is something that you, personally, cannot live without? Isn't this exactly why optdepends exist?
Comment by Eli Schwartz (eschwartz) - Sunday, 15 September 2019, 22:37 GMT
And also, I don't really understand what the purpose is of opening a new bug and calling it "related" to this other bug, is.  FS#39056  already asserted that wifi-menu has a hard dependency on netctl, and requested one of two solutions for the netctl package, to either split out wifi-menu into a new package or to elevate dialog into a hard dependency.

You've opened a perfect duplicate, while restricting yourself to only recommending the former proposed solution.
This is not "partially related".
Comment by Muflone (muflone) - Sunday, 15 September 2019, 23:57 GMT
> But no, really, why do you assume that netctl is fundamentally "unusable" just because the non-core functionality is something that you, personally, cannot live without? Isn't this exactly why optdepends exist?

A part of the netctl package functionality is to offer the wifi-menu tool. At the actual state, wifi-menu is not working as its main and only functionality is not available **at all** until the optdepends are installed.

 FS#39056  was about adding the dialog dependency to the netctl package, while  FS#63777  is about to move wifi-menu out of netctl package, not to add the dialog dependency to the netctl package.
Comment by Eli Schwartz (eschwartz) - Monday, 16 September 2019, 00:26 GMT
And a part of the glib2 package functionality is to offer the tools gdbus-codegen, glib-genmarshal, glib-mkenums, gtester-report. Those require python, because they are python scripts. I assume we don't want to add python to the mandatory base install, though???

Do you consider this a matter of principle, that all packages which provide an *optional*, *non-core* script whose "only functionality is not available at all" must be split into a split package which provides these tools?

If so, you are honor bound to submit similar reports for glib2 and many, many other packages. I promise you I've got lots more examples.

...

 FS#39056  was absolutely not about adding the dialog dependency, as even a cursory reading of it will reveal. Shall we quote some of it?

Sentence #1: Problem the ticket is describing.
> netctl owns /usr/bin/wifi-menu, yet this is unusable because it expects dialog library on the system.

Sentence #2: Proposed solution.
> Either move wifi-menu to a separate package, or make netctl depend on dialog.

Loading...