GNOME Bugzilla – Bug 684897
don't bundle applications
Last modified: 2021-05-26 22:24:27 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.
(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.
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?
(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.
Hmm, ok so maybe we should just set NoDisplay=true for both of them then (for now) and they can still be run explicitly.
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.