The new gnome-software application

Richard Hughes hughsient at gmail.com
Tue Mar 5 21:02:22 UTC 2013


On 5 March 2013 20:02, Ryan Lerch <rlerch at redhat.com> wrote:
> Does this mean that the Application data will be something that Fedora will
> need to host in addition to the data already in the packages?

Depends if Fedora wants to have application icons and translated
descriptions -- See https://bugzilla.redhat.com/show_bug.cgi?id=488968
for all the grotty detail. I'm not going to solve that one as I burned
out pretty hard a couple of years ago fighting with people. I'm happy
to design the tools to be pluggable and for someone in Fedora to give
me some metadata and a way to update it. If that's a XMLRPC call, a
bit of yum metadata or a separate package I don't care. Sorry if this
sounds harsh, but I got pretty upset with the behaviour of some people
in Fedora back when we were designing AppStream and I don't want a
repeat of that.

> Also, the current mockups for the applications page on GNOME wiki don't have
> any ratings or comments for applications.

It's got ratings in the application details page. Where that data
comes from for Fedora is still unknown, but I was hoping to harvest
some data from pkgdb. It doesn't have to be updated in real-time,
ratings will change slowly, and we probably want to game the system a
little at first anyway.

>   Was this something that was
> considered in the design? (although this sounds like it will encounter the
> same issue as the application data, needing something external outside the
> packages)

Comments are tricky. Comments need people to review them (mark as
inappropriate,etc) and also need to be handled per-locale, i.e.
there's no point in showing a French comment to a Japanese user, which
means per-locale moderation. I'm not sure comments are particularly
useful. Tags on the other hand are...

> Have you got any further information on the design thinking behind the "OS
> Updates"? will that just install all the non-applications packages that are
> available at the time?

At the moment, the heuristic is "it's an app, new entry, otherwise
stick in os-updates" -- so it includes stuff like -devel, -debuginfo
-libs etc. Not ideal at all, but that's the price we pay for having
everything so granular as packages.

>  furthermore, if one of my applications needs a
> separate package updated as a dependency, will it install the entire "OS
> update"? or will it just update the packages are required to update that
> application?

Just the required packages, not everything. And it currently updates
the deps without even asking, which is a feature not a bug.

> Finally, even though they aren't GUI applications, should standalone
> terminal applications (e.g. mutt, irissi or vim) also be considered an
> "Application"?

Nope, applications have desktop files that get shown in the GUI menus,
with a few things blacklisted. Anything other than than leads you down
a slippery slope where stuff like openldap and abrt become
applications, and then you've got no concept of a base-os any more.
It's my personal opinion of course, but I've been thinking about a
good way of delineating and defining applications|base-os for quite
some time. If something like GVim ships a desktop file, then it'll get
included, vim not so. irissi is a power user tool, and those kind of
people are quite comfortable doing "yum install irissi" or "zif
install vim"

Richard.


More information about the desktop mailing list