maemo at subs
Nov 26, 2009, 4:45 AM
Post #8 of 46
(1387 views)
Permalink
|
On Wed, Nov 25, 2009 at 10:24:02PM +0000, Valerio Valerio wrote:
> one of the topics of the last community meeting about Extras QA was if
> command line applications should be available for regular users through the
> application manager or not.
I was wondering what happened to that, thanks for bringing it up :-)
> We're talking about apps that doesn't have a UI nor place a icon in the
> desktop, nor are simple enables that display a message during/after
> installation.
It's actually a bit more complex than that as there are several axes to
consider (end-user/techie, GUI/text-mode, user/system off the top of my
head, probably more). For example we could have command-line apps that
run in osso-xterm like mc and vim, system daemons that run in the
background like sshd and ntpd, and even GUI tools that some may consider
inappropriate for "regular" users like wireshark or gconf-editor.
At the end of the day I don't think it matters that much. The core
issue is whether these packages, whatever they may be, are managed
properly.
> Pro arguments:
>
> - We want CLI apps to be available via H-A-M, so that the user sees updates,
> can restore them after reflash and so on.
> - Suppose tomorrow a security hole is found in openssh, if it's not visible
> in h-a-m how will users know about it?
This is the biggest issue IMHO. In plain words: the platform package
management is a Good Thing(TM), and packages shouldn't fall
outside it, especially not for arbitrary reasons like they don't have a
GUI.
> - As long as the description makes clear that this
> runs-in-background/in-X-Terminal/...
That's fine, and could even be added to the QA checklist. We could even
have a special icon indicating non-GUI status in h-a-m.
> - Yes, if there's a appropriate category for these apps.
> - New user/cli (or, with a subsection-aware HAM, user/network/cli and
> user/desktop/cli) for them.
+1 for the subsection version. I'm also fine with an application
manager option to hide them from the available list (but not from
updates!), even if it defaults to on.
> - For some CLI apps (mc,pico,nano,htop,etc) you can actually create a
> desktop file that launches app inside an xterm. Can we generate such files
> effectively making apps desktop-based?
For some it's an option (though I personally think the vim launcher is
next to useless and I'm not convinced that cluttering the already
dysfunctional app launcher with more icons is the greatest idea in
general), but it doesn't make sense for daemons that are meant to be
running all the time or programs that expect arguments on the command
line like wget, socat or ssh.
> Con arguments:
>
> - The experience that a ordinary user would have with the bash shell from
> extras would be bad.
Well, better than the experience with the busybox /bin/sh at any rate :-)
> - The ones that will use CLI apps, have enough knowledge to install them via
> apt-get.
If they are even aware of them in the first place, and then there's the
matter of keeping them updated, remembering which ones to re-install
manually after a reflash etc. It's a horrible user experience :-(
Besides, as long as "apt-get upgrade" isn't a completely safe operation
we really shouldn't be telling any users to use apt.
> - Ubuntu/fedora... hide these apps in there app managers
The latest Ubuntu adds "Ubuntu Software Centre" which does this, but
synaptic (which doesn't) is also installed by default. Users get
prompted with available updates for all installed packages of course.
In Fedora, PackageKit doesn't hide anything. It has end-user/developer
and graphical/text (heh, someone gets that these are different things
after all) filters, but unless I'm very mistaken they default to off.
In both cases everything is available without having to go into "here be
dragons" repositories, and once installed (even if on the command line
with apt/yum) those packages are also managed by the GUI package
managers.
> because these aren't suitable for regular users.
I would prefer to allow users decide that for themselves.
> - CLI apps are for devs
I disagree. There are packages like openntpd which are useful to
everyone, other packages may be dependencies of GUI apps and so on.
> and people who can handle extras-devel.
The main problem with that is that enabling extras-devel is an
all-or-nothing option, and /can/ result in system breakage depending on
what else is there at the time.
Another problem is that if they are stuck in -devel they are effectively
also outside the QA process, which benefits no one.
> - Applications which don't auto-start/plugin and have no non-X Terminal way
> of starting do not get into Extras.
The only possible outcome I can see from such a policy is maintainer
frustration leading to lots of third-party repositories cropping up and
inter-repo dependency hell all over again.
So, in case it wasn't clear I'm 100% on the Pro side of this :-)
L.
_______________________________________________
maemo-community mailing list
maemo-community [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-community
|
signature.asc
1
