[arch-general] netctl provides wifi-menu which is unusable

[Dennis Herbrich]

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