unaccessability

[Michael Schwendt]

On Sun, 10 Nov 2013 18:02:46 +0000, Ian Malone wrote:

> You are arguing that system management should only be possible through
> a GUI where the affected components are themselves graphical.

No, not at all.

> Please take some time to reflect on how ridiculous that is.

http://fedoraproject.org/code-of-conduct

> Should non-gui packages be excluded from automatic updates because the
> tool used to manage that is graphical?

What do "automatic updates" have to do with this?

The updater could continue to cover *all* packages as registered in the
RPM database. That doesn't need to happen within the same GUI as the
application installer.  A desktop user, who added LibreOffice to an
installation using a graphical application installer, is not interested
in how many low-level "packages" and "dependencies" LibreOffice is split
into and that from time to time such dependencies are updated with or
without affecting LibreOffice.  A "System Updates" tool that handles all
updates of installed low-level "packages" could be a completely different
piece of software.

Btw, currently, when I run "gnome-software" and click "Updates", it
claims "Software is up to date", but Yum finds updates:

  # yum check-update|wc -l
  39

> Should firewall management be only possible at the CLI? 

No. And firewall-config is a GUI.
I don't understand why you've asked that question.

> I'm looking at the software management menu
> in KDE right now and on my system there are 26 entries listed in the
> servers management section, since these are non-graphical should they
> be dropped?

I don't understand why you've asked that question.
It seems to me you may have misunderstood something _completely_.

What I don't like is the situation that somebody uses a graphical tool to
install "software", and the installed stuff doesn't show up anywhere in
the graphical desktop user interface (such as a menu system), but is only
listed as installed. That's the "WTF?" scenario, where the user needs to
be an expert to figure out that the installed thing is CLI-only (or not
even "executable" at all) and something that cannot be "used" from within
the desktop UI. 
If an "application installer" will be able to install arbitrary
"packages", I would welcome a very obvious distinction in the UI,
a special interface for specific types of components and "add-ons".
Not old-school ambiguous "categories". What I don't like is a graphical
"package tool" that tries to handle the 40,000 "packages" by sorting them
into categories. And the user is confronted with many thousands of "lib"
packages, for example, which are no "applications" (no "programs" to
use). A developer (or a sysadmin) has different requirements.