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