Created attachment 182589 [details] [review]
Don't show Service Pack Creator in application view

How is the user supposed you launch this tool? There are no other links to this executable.

I don't really think this tool should be installed by default to be honest.  This is one of the problems with a module installing lots of separate tools/apps.

In that case, NoDisplay is the wrong solution. Instead, fix the packaging to make this a separate subpackage.

I don't have a package.  Either it is removed from the module or you add NoDisplay=true.

_Wrong_ _solution_

This is a core GNOME module.  It has different requirements.  Downstream packaging changes are not a solution to this.  It must work upstream too.  This Service Pack Creator is not something any end user would ever want to use, it isn't something that GNOME developers want to use, it isn't something that any distro I know of uses.  Therefore it does not belong in the default GNOME install.

Stuffing a bunch of apps into a core module that provides a service isn't usually a good idea.

I would personally remove this tool from this module and consider moving it somewhere else if it is really needed.  But I would settle for just hiding the desktop file until you figure out a better solution.

Fixing downstream packaging is not the answer.  Can we please just add a NoDisplay or move the tool to another packagekit-extra-tools module or something.  Or if you don't have time to do that now you can resurrect it from git after removing it from here.

I think using a distro sub-package is the best plan at this stage. We can revisit for 3.2 if we need to.

It is important for the upstream experience to work.  We can't just punt the problem to distributions.  Something like packagekit that is a core dependency should not add things to the GNOME 3.0 application view that aren't don't make sense for pretty much anyone and haven't been designed at all.  Can you please remove this tool for 3.0 upstream?

I think there are two sort of separate things here - there's a question of how we deal with advanced-level tools that are built as part of core packages - an example of this is dconf-editor which is built as part of dconf. The Windows approach is esentially NoDisplay - you have to get to regedit or whatever from the run dialog. I'm not a huge fan of this - I think it's better if all installed applications show up in applications and applications that a user doesn't need aren't installed.

But it's hard to map an application installation model to jhbuild because jhbuild at best gives you an "OS base image" - there's no application repository or whatever on top of it.

So, in terms of how we deal with dconf-editor, I don't have a good answer. My feeling is that if we believe in "install the applications that you want to use" if there's no basic difference between dconf-editor and glade and some circuit layout editing program, then we have to use subpackages at the distro level, deal with it in jhbuild and put pressure on people not to put useful apps into the repository 

But honestly, gpk-service-pack-creator seems a level further removed. It's experimental - something that seems like an interesting idea, but though it's been around for 2-3 years has very little uptake - and I'm not sure there's a great understanding of what it's for. The most interesting use case seems to be "I want to do a fresh install and then replicate all the applications I have installed here on that computer", but you'd never know to click on something labelled "Service Pack Creator" to do that, and it's not really obvious once you do what is going on or how I'd install the package list somewhere else.

The basic idea of GNOME 3 is that we have pretty large applications - they are big chunks of functionality - not little discrete chunks of functionality - and so if there was some sort of functionality to export a list if applications, I'd expect to find it, say, in Add/Remove Software - maybe that would have in it's file menu

 Export Application List
 Import Application List

Or something like that. 

In any case, maybe picking on Service Pack Creator as needing rethinking seems unfair here, since there are other things like dconf-editor that fall into the same boat of being questionable whether we want to show them or not. But on the other hand, having a big existential discussion about whether advanced tools should be in the menu doesn't seem appropriate if we're talking about something that really is pretty marginal. After all, in:

http://blogs.gnome.org/hughsie/2008/11/15/pkcon-list-install-foopackage-list/

After showing the screenshot, you ended up doing everything from the command line. Is that necessarily a bad way of doing things? Advanced users like command line tools.

So my vote here would be with Jon for NoDisplay=none, not because I think jhbuild is going to ever be a real answer for how we package applications for GNOME but because I'm not sure this application is yet really worth spending a lot of time chasing distros to put in a separate subpackage - and because it just doesn't feel like an app to me.

(In reply to comment #11)
> So, in terms of how we deal with dconf-editor, I don't have a good answer. My
> feeling is that if we believe in "install the applications that you want to
> use" if there's no basic difference between dconf-editor and glade and some
> circuit layout editing program, then we have to use subpackages at the distro
> level, deal with it in jhbuild and put pressure on people not to put useful
> apps into the repository 

The last sentence was meant to say something like"

 "and put pressure on people not to combine useful, but optional, applications into the same git repository as core libraries"

(In reply to comment #11)
> "I want to do a fresh install and then replicate all the applications I have
> installed here on that computer"

Most people don't use it for that. In the US and most of Europe most people don't use ever need this tool. It's most useful to download a "pack" of updates on one computer and share it with other people on a CDROM or USB stick. This is useful if only one computer in a room is connected to a network, or when people have to pay ludicrous amounts per megabyte in developing countries. Do you need to use this tool? No. Do people in India, Pakistan, Uruguay use it, Yes (and I get the "thank you" emails to back that up).

I'm sure the UI is pretty crappy, and I'm sure the UI could be folded into gpk-application, but it was designed as a standalone executable so we wouldn't bloat the gpk-application UI with options that most GNOME users do not need.

(In reply to comment #12)
>  "and put pressure on people not to combine useful, but optional, applications
> into the same git repository as core libraries"

I think that needs to be communicated to developers, as most projects just create one tarball with a suite of tools. Think of GIMP or libreoffice, for example.

I've applied the patch from Jon, but I think it's a shitty fix. I'm also really unimpressed with the way bugs like this are being handled.