[maemo-developers] What category should network filesystems like OpenAFS go under?

[From: Eero Tamminen]

Hi,

ext Mike Lococo wrote:
>> But I do think that there should be a category specifically for command line 
>> tools so that people who do not use the command line don't have to waste time 
>> on them.  And I also agree that a GUI configuration dialogue for a system 
>> tool is much better than expecting someone to edit a config file.
> 
> This stikes me as a similarly flawed approach.  Terminal-based 
> applications have the same range of functionality that graphical 
> applications have, so you either need to duplicate your category list in 
> two places (and force users interested in both types to look twice), or 
> you stop categorizing terminal-apps altogether (and leave users that use 
> them with the bad categorization problem we have now).
> 
> Some alternate approaches...
> 
> - Standard labels: A -cli suffix at the end of each app name would allow 
> users to quickly recognize and skip terminal apps if they aren't 
> interested in them.  Even just including a note in the description would 
> be sufficient in my mind.


Most of these packages come unmodified from Debian, so changing
the package name is not really good solution.  Having this
in description is even worse, AM couldn't filter them out for
normal users ("aunt Tilly").


> - Debtags-based searches: Give AppMgr a real search facility, and ship 
> canned-queries like "graphical apps", "terminal apps", etc.
> 
> - Advanced-Browsing mode: With proper package classification and the 
> existence of extras-devel to hide truly dangerous apps, red-pill (or 
> something similar) could be made into a more discoverable "advanced 
> browsing" mode that hides end-user apps that are likely to be 
> uninteresting to grandma-types that folks seem so concerned about.  Give 
> it a normal preference checkbox, and have it do some debtag or other 
> magic to hide complicated stuff, while making it easy and safe for users 
> who want to see the full range of available software.  I do think any 
> binary solution like this which is aimed at hiding apps that are "too 
> hard" will ultimately prove to be unscalable and unhealthy for the 
> community, which depends on folks discovering challenges which interest 
> them and choosing to learn something new.  If the binary filtering is at 
> least easy to disable/ignore, as proposed above, the damage will be 
> minimal though.

Showing by default only packages with certain tags and having some
UI for configuring which to show sounds fine to me, but upstream
Debian compatibility should be kept in mind when designing this
(which tags to use, propagating tag changes back to Debian etc).



	- Eero