After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 684897 - don't bundle applications
don't bundle applications
Status: RESOLVED OBSOLETE
Product: tracker
Classification: Core
Component: General
unspecified
Other Linux
: Normal normal
: ---
Assigned To: tracker-general
tracker-general
Depends on:
Blocks:
 
 
Reported: 2012-09-26 17:10 UTC by William Jon McCann
Modified: 2021-05-26 22:24 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description William Jon McCann 2012-09-26 17:10:35 UTC
Currently tracker (the service component) bundles a bunch of applications with it. Since tracker is a required component for GNOME it really shouldn't install these tools as a side-effect.

Could we separate these out into a tracker-tools module?

Distributions already do this but this would help those of us running
jhbuild or ostree builds, and it is desirable for those to reflect the end user experience that we are aiming for.
Comment 1 Martyn Russell 2012-09-27 08:57:59 UTC
(In reply to comment #0)
> Currently tracker (the service component) bundles a bunch of applications with
> it. Since tracker is a required component for GNOME it really shouldn't install
> these tools as a side-effect.

Which applications are we talking about here?

You could split the binaries into the following categories:

 - Store
 - Command line tools (absolutely necessary in my experience in all cases)
 - Miners (including tracker-miner-fs, without which Store is largely redundant)
 - User interfaces (useful ones to users, like tracker-preferences, etc)
 - Development interfaces (like tracker-explorer)

So my question would be, which of these do you want in a separate module?

There are quite some binaries produced in the Tracker project.
 
> Could we separate these out into a tracker-tools module?
> 
> Distributions already do this but this would help those of us running
> jhbuild or ostree builds, and it is desirable for those to reflect the end user
> experience that we are aiming for.

That sounds like a lot of work for very little or no gain.

While I think it's probably a good idea, there are a lot of things to consider here. For example, some of the applications are related to the built components below (e.g. tracker-preferences is not built if tracker-miner-fs is disabled). So if we split these into different modules, we have to have additional checking in the build of a potential UI module.

The disruption here would affect distros too and packaging Tracker is already quite a large task. Most of this effort goes into the underlying core of Tracker, not the user interfaces.

If we were to do this it would make sense for the next stable iterations only (i.e. we should start a 0.15.x release branch to test this stuff).

As for the name "tracker-tools" I prefer something a bit more direct. To suggest anything else I would need to know what exactly you think makes sense to go in there.

Note, the UIs really are just:

  --enable-nautilus-extension
                          enable the nautilus extension [[default=auto]]
  --enable-tracker-search-bar
                          enable tracker-search-bar[[default=auto]]
  --enable-tracker-needle enable tracker-needle [[default=auto]]
  --enable-tracker-preferences
                          enable the tracker preferences dialog
                          [[default=auto]]
  --enable-tracker-explorer
                          enable tracker-explorer[[default=auto]]

These are all quite small AND easily disabled at build time. So I question the usefulness of investing time on this.
Comment 2 William Jon McCann 2012-09-27 13:10:49 UTC
The problems are the ones with desktop files that don't have NoDisplay=true. Seems to be:
 * tracker-needle
 * tracker-preferences

We don't want either of these appearing in the application view.

For 3.7 we should probably add relevant parts of tracker-preferences to either the system settings or the nautilus preferences. I'm not sure we need tracker-needle installed by default at all. It seems more like a test application.

Perhaps instead of splitting the module up we can just disable these two by default?
Comment 3 Martyn Russell 2012-09-27 15:20:59 UTC
(In reply to comment #2)
> The problems are the ones with desktop files that don't have NoDisplay=true.
> Seems to be:
>  * tracker-needle
>  * tracker-preferences
> 
> We don't want either of these appearing in the application view.

I think this makes sense to fix in the desktop files definitely. I totally hate seeing useless or secondary, etc apps showing up in the app overview.
 
> For 3.7 we should probably add relevant parts of tracker-preferences to either

I agree here, I've wanted this for a while now. Not sure what's involved yet.

> the system settings or the nautilus preferences. I'm not sure we need

I don't think Nautilus is the right place - well... it might be. It's quite a big set of preferences to add *onto* Nautilus' preferences, but as a separate section perhaps it could make sense.

The problem for me on this one is that GNOME Documents is using Tracker as are other apps - so it makes this a little less intuitive to find IMO.

> tracker-needle installed by default at all. It seems more like a test
> application.

Well, with Nautilus more actively using Tracker in the new GNOME 3.6, you're likely right - but some people like it. It is more of a demonstration tool.
 
> Perhaps instead of splitting the module up we can just disable these two by
> default?

So here is my concern - Tracker is free for people to use it however they want in their platform, but if you check out the product, install it, run it. Then think what can I do with it - having UIs disabled by default makes it harder to see the show cases, like tracker-needle and to find tracker-preferences to configure it.

If this is just about GNOME, why not specify how it is built there? Each distro does different things with Tracker too.
Comment 4 William Jon McCann 2012-09-27 20:55:37 UTC
Hmm, ok so maybe we should just set NoDisplay=true for both of them then (for now) and they can still be run explicitly.
Comment 5 Sam Thursfield 2021-05-26 22:24:27 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new enhancement request ticket at
  https://gitlab.gnome.org/GNOME/tracker/-/issues/

Thank you for your understanding and your help.