Wifi-menu as a separate package makes the most sense, avoids the issue of some netctl users not wanting wifi-menu, being able to configure their networks themselves or using something else to search for wifi networks. On Wed, Feb 26, 2014 at 8:35 PM, Daniel Leining <daniel@the-beach.co> wrote:

Yeah, I agree on this. It should be a dependency of netctl, or wifi-menu be a separate package with dialog as a dependency.

Just my two cents.

-- - Toyam

On Wed, Feb 26, 2014 at 08:56:34PM -0600, Garrett Hopper wrote:

This would be great. It's always annoyed me that it's sitting there unusable.

I don't usually play this card, but netcl takes up 7 kilobytes of disk space---an infinitesimal amount relative to many core *NIX utils---and only runs when executed by a user. Yes, I know that coreutils gets used a whole lot more than wifi-menu, but still... How much simpler can you get in this case? You could ditch netctl entirely and just use wpa_supplicant directly, provided you're not bothered by a wifi connection program that includes an interactive shell you may never use. As for dialog, If it is a dependency for netclt that's not explicitly declared, then a bug report should be filed (if one isn't already; there's a big systemd update coming not long from now, so netctl may be getting updated soon as well and the devs may already be on this).

----------------------------------------

To: arch-general@archlinux.org From: 31337h4ck3r@gmail.com Date: Thu, 27 Feb 2014 04:44:20 +0000 Subject: Re: [arch-general] netctl provides wifi-menu which is unusable

Nowaker <enwukaer <at> gmail.com> writes:

...

Hey,

Why does netctl provide /usr/bin/wifi-menu which is unusable at all, given the fact it needs /usr/bin/dialog to operate, and this is not a hard dependency of the package?

I don't really get a point of providing a binary/script that doesn't work at all. What is it in the package for?

If adding a dependency on dialog (big deal - 200KB) is not an option, why not extract wifi-menu to a separate package? This sounds like the best approach - the package could depend not only on dialog, but also on wpa_supplicant, dhcpcd and other package that anyone installs anyway to get wifi-menu working.

Have you looked at netctl's optional dependencies? It lists dialog along with the message "for the menu based wifi assistant". The other packages like dhcpcd and wpa_supplicant are also optional dependencies.

He knows it's an optional dep. He filed a bug report and specifically said "No, optdepend is not desired.". The bug report was immediately closed as an optional dep is correct. I've really got to wonder what the rational is here, he doesn't want to pay attention to pacman's output, maybe?

Optdepends are used for software like lighttpd or apache where some optional modules may need these optdepends. /usr/bin/wifi-menu is a first class citizen of this package, not just some optional module. wifi-menu isn't so much a "first-class-citizen" as it is a graphical interface to the netctl backend.

I don't know of any other package that would do the same. I know of several packages that optionally depend on graphical interfaces to provide a graphical interface to the program. Of the top of my head I can think of nmap which optdepends on pygtk for

On 27/02/14 at 13:22, Nowaker wrote: the zenmap binary. There are more, and I think that is a perfectly valid use case.

I do pay attention to the output, but current state of wifi-menu in netctl is a nonsense. And what is a nonsense needs to be fixed, right? Three other people already agree with me.

I don't consider this nonsense, wifi-menu is not an essential part of netctl so dialog shouldn't be in the depends. wifi-menu also isn't important enough to receive its own package. I see zero problem with wifi-menu remaining a binary in netctl that requires an optdepend in order to function because wifi-menu does nothing extraordinary but provide a simple user interface to netctl. To sum it up: the status-quo is fine as it is. There is no point in changing something that not only works but also makes perfect sense. -- Simon Thelen Yes, I've now got this nice little apartment in New York, one of those L-shaped ones. Unfortunately, it's a lower case l. -- Rita Rudner

Guys, the goal of this "slanted ranting" (really?) is to propose a good solution and make Arch better. Please think out of the box and answer one question: Would a separate netctl-wifi-menu package that depends on dialog, wpa_supplicant and dhcpcd be better or not - and why? My answer is yes: it will make wifi-menu usable to anyone who wants to use wifi-menu and installs the package. I am really opposed to answers like "No, because that's why the maintainer wanted this package to look like". Any good idea can be denied with this type of argumentation. -- Kind regards, Damian Nowak StratusHost www.AtlasHost.eu

On Thu, Feb 27, 2014 at 06:10:39PM +0100, Nowaker wrote:

Guys, the goal of this "slanted ranting" (really?) is to propose a good solution and make Arch better.

Please refrain from implying that the current state needs being made better in the first place. This is exactly what we're trying to determine here.

Please think out of the box and answer one question:

Would a separate netctl-wifi-menu package that depends on dialog, wpa_supplicant and dhcpcd be better or not - and why?

I'm sorry to say that, but packaging policy is exactly that: A policy. As such, it is based on "politics", guidelines and vague, general ideas of how things should be done. If you put your foot down and require a logical, objective argument, let me refer to Arch's policies/guidelines: https://wiki.archlinux.org/index.php/Arch_Packaging_Standards Unfortunately, these Packaging Standards do not rationalize this question. No luck there. Maybe that should be amended? https://wiki.archlinux.org/index.php/PKGBUILD#optdepends "An array of package names that are not needed for the software to function but provides additional features." https://wiki.archlinux.org/index.php/PKGBUILD#depends "An array of package names that must be installed before this software can be run." If wifi-menu was an independent package, it would depend on netctl/dialog to run, and could be included itself as an optdepends in netctl, thus implicitly installing dialog when selected. This is, admittedly, a clean solution in spirit of these guidelines, and would also decouple wifi-menu development from the netctl package, allowing it to be placed into [extra] or even the AUR. However: wifi-menu is a single, 7k shell script that has no other use but to provide a "graphical" way to create wireless netctl profiles. It does not bloat the netctl package. It is also NOT developed by a third-party, so we'd be introducing an artificial independence where it's not really a necessity. Creating (and maintaining!) an explicit package just for wifi-menu is, from a maintainer POV, additional effort, putting strain on an already limited resource. Putting this argument to a test, imagine yourself consequently splitting packages where possible: You'd end up with a perl/python/ruby situation, with functionality "tidbits" being scattered across dozens or hundreds of packages. This is an unnecessary complication for the user base. Frankly, I personally consider the decoupling of packages as a "good thing", but not without sound reason, to keep the package management overhead as small as possible. Where to draw the line is subjective, however. *IF* wifi-menu was actually maintained by a third party, splitting it from netctl would be a no-brainer, also if it had a larger footprint than 7k. As it is, however, it is maintained by the netctl developer, and the argument "It is simpler that way for the dev" cannot just be brushed aside for an abstract architectural "niceness" argument. Effectively, the dialog package we're fussing about is installed on practically all Arch installations, anyway, leaving the original point rather moot. I'm sorry that this bit you, but I find it difficult to see merit in maintaining a new package to turn an optdepends into a depends for a package (dialog) that is installed regularly, anyway, AND that is advertised as an optdepends when netctl is installed, without which wifi-menu doesn't fulfill any purpose. Please note that I'm not a developer (anymore). I do, however, use Archlinux for 12 years now, many years professionally and as a packager for custom repos. If anything, consider this opinion as a result of experience and associated trauma. ;) Best wishes, Dennis -- "Den Rechtsstaat macht aus, dass Unschuldige wieder frei kommen." Dr. Wolfgang Schäuble, Bundesinnenminister (14.10.08, TAZ-Interview) 0D21BE6C - F3DC D064 BB88 5162 56BE 730F 5471 3881 0D21 BE6C

----------------------------------------

Date: Thu, 27 Feb 2014 13:22:50 +0100 From: enwukaer@gmail.com To: arch-general@archlinux.org Subject: Re: [arch-general] netctl provides wifi-menu which is unusable

...

Have you looked at netctl's optional dependencies?

Of course I have but the question is - what is the point of providing a binary that doesn't work at all without some optdepends?

Optdepends are used for software like lighttpd or apache where some optional modules may need these optdepends. /usr/bin/wifi-menu is a first class citizen of this package, not just some optional module.

I don't know of any other package that would do the same.

Virtually every other package that has optional dependencies does the same. Almost all of them have binaries that don't work without the optdepends installed. I don't know where you get the idea that wifi-menu is a "first class citizen", it's non-essential functionality which is exactly why it's dep is an optdep. Remember, it's the author of the program that made it an optdep.

...

I've really got to wonder what the rational is here, he doesn't want to pay attention to pacman's output, maybe?

I do pay attention to the output, but current state of wifi-menu in netctl is a nonsense. And what is a nonsense needs to be fixed, right? Three other people already agree with me.

Three other people agree with your slanted ranting where you don't give all of the information. So what? It wouldn't matter even if they do agree with you, Arch isn't a democracy, the maintainer/author makes the decision.