As we mentioned in our GUADEC 2020 talk, it’s a complex task to coordinate the changes in Tracker with the various places Tracker is used in GNOME. We didn’t know if it’d be possible to port everything in a single cycle. In fact, we still don’t know! I put out a call for testing which may lead to us discovering some critical issue. Our initiative to port all apps to Tracker 3 is still in progress too – some of the tasks depend on volunteer maintainers having time to review changes.
The good thing about making Tracker 3 parallel installable with Tracker 2 is that we have options. Our “Plan B” for the GNOME 3.38 release, if it’s not possible for every app to update to Tracker 3 in time, is that GNOME 3.38 would depend on Tracker 2 for full-text search and the apps which aren’t ported, but we would release a “off-by-default” Tracker 3.0 that the apps which are ported can use to index e.g. the ~/Music directory.
@kloczek made the point that it’s difficult to have a ‘tracker’ package that upgrades cleanly from tracker 2.x to tracker 3.x if the systemd services change names. I don’t have a good answer for that. I am wondering if – given that we may yet have to do the “Plan b” described above – we should ask distributors to create a new tracker3 package in all cases.
@kloczek made the point that it’s difficult to have a ‘tracker’ package that upgrades cleanly from tracker 2.x to tracker 3.x if the systemd services change names. I don’t have a good answer for that. I am wondering if – given that we may yet have to do the “Plan b” described above – we should ask distributors to create a new tracker3 package in all cases.
It is not about difficulty with packaging.
It is about issues which will cause new name of the systemd service. Part of the typical upgrade procedure is restart service. Because service name is changing here will be necessary to apply some special (not typical) upgrade procedure.
In this case
In that case that part is not even so imprtand as answetro on the question: why gettext domain, glib service systemd service name and binaries names are changeling.
So far I was not able to find any rational resins for those changes together.
So far on the conversation Sam told that definitely old tracker will be not used at the same time with new tracker. This means that all those naming changes are not justified from that angle.
Question is: is any other reason what all those naming changes are done?
If not automatically it will mean that that part should be rolled back.
Aa ABI/API changes I’m not against pkgconfig name change and/or library SONAME change as well.
However even base path of the header files seems could rolled back.
All what I’m trying to tell is that on such changes KILL principle should be applied.
I guess you specifically talk about tracker-miners. Keep in mind that tracker-miners 2.x and 3.x are not interchangeable, each version populates data to the users of its respective version.
Shipping tracker 2.x alone satisfies built time dependencies, but remaining applications depending on it will be uselessly devoid of content, or with forever stale data. The apps that migrated to 3.x would be equally broken if tracker-miners 3.x wasn’t shipped.
The separation from our perspective makes sense and is going to stay.
As pointed out, we’ve taken this approach to make it possible to migrate as smoothly as possible between both versions, this can also happen beyond our control (e.g. distros mixing applications we didn’t have time to migrate with others we did).
We don’t want to hinder migration to 3.x just because packagers are forced to pick one set of miners. Making a distinct tracker3-miners package is a possibility, these are essentially different binaries.
I guess you specifically talk about tracker-miners. Keep in mind that tracker-miners 2.x and 3.x are not interchangeable, each version populates data to the users of its respective version.
I’m aware of that. However I’m talking about scenario when someone is trying to make an upgrade from all tracker 2.x to new 3.x binaries.
In other words it is about impact of those changes on packaging layer when on upgrade all tracker 2.x binaries to 3.x. Is it really necessary to make all the naming changes? Answer is no.
In typical upgrade transaction all binaries will be replaced and than because it will be upgrade exactly the same tracker service could be restarted. Wit new name of the service introduced that process will be not smooth and because tracker migration 3.x only started and only tracker-miners is ready still is possible to avoid clashing with all those issues.
In other words ABI changes does not need to be followed by all binaries, gettext domain and other names changes. Do you see my point now?
If we made the solution that suits you like a glove, how are distributions that may expect a mix of Tracker 2.x and 3.x users going to package both?
Between de-facto forbidding any mixture whatsoever of 2.x and 3.x users, and making things inconvenient to the distros that want to act as if these actually weren’t different binaries, I’m afraid you’re in the losing end.
There’s software out there that still does depend on Tracker 2.x and even if we’ve had enough time to update them all, they are way beyond our control
and release schedule (not just non-core GNOME apps, but eg. samba or netatalk). Again, we do not want to force all distributors to a go/no-go decision, we do not want to hinder migration to 3.x from starting ASAP, we’re not going to throw a spanner in the works. We must make it possible to run both sets of daemons simultaneously.
That is not about what suites me or making me happy.
That scenario will be valid in case of all Linux distributions as all of them are trying to restart package services during upgrade.
Between de-facto forbidding any mixture whatsoever of 2.x and 3.x users, and making things inconvenient to the distros that want to act as if these actually weren’t different binaries, I’m afraid you’re in the losing end.
There’s software out there that still does depend on Tracker 2.x and even if we’ve had enough time to update them all, they are way beyond our control
Again: I was already told that no one is going to handle scenario when tracker 2.x and 3.x will be installed on the system. What happens now during porting all projects which are using tracker ABI to 3.x is competently different story.
As main tracker ABI and service theoretically on all systems will be only one instance (2.x or 3.x) it is possible to reuse all filenames except library SONAME, base directory used for header files and pkgconfig file name.
All those bits could be different because they are not affecting stage when produced binaries in form of dist packages will be used on end systems.
As I see tracker 3.x changes are a bit deeper so all clients which will be not ported and rebuild for 3.x will be not able to talk with tracker 3.x main service. In other words trying to analyse scenario when some other projects will be not ported to 3.x is a bit pointless. Am I right?
As I see tracker 3.x changes are a bit deeper so all clients which will be not ported and rebuild for 3.x will be not able to talk with tracker 3.x main service. In other words trying to analyse scenario when some other projects will be not ported to 3.x is a bit pointless. Am I right?
The first part is correct – Tracker 2 and 3 have different, incompatible interfaces for apps. However, as discussed at Improve data sandboxing by using Tracker 3 (#17) · Issues · GNOME / Initiatives · GitLab, GNOME is a volunteer driven project with a fixed release schedule. We cannot 100% guarantee that everything will be ported and working in time for the release on 12th September, and we need a contingency plan. That’s why we have made 2.x and 3.x parallel installable. We very much hope not to need this safety net, but we would be unwise not to have it.
We cannot 100% guarantee that everything will be ported and working in time for the release on 12th September, and we need a contingency plan
My concern is only about main tracker package and service and all related to that changes in names.
That part is already done.
On what I’m trying to encircle is completely not related to tracker consumers/clients.
Looks like main service 2.x and 3.x will be not compatible and running main tracker 3.x and clients using 2.x ABI/API looks like will fail. From that point of view gettexrt domain name change and changes in used executables are meaningless → Ergo: tracker 3.x can reuse old binaries names and gettext domain.
If an app is not ported to Tracker 3.x in time for GNOME 3.38, then it needs to use Tracker 2.x.
In the end, this is happening with GNOME Photos – the port is not ready for release, so it will depend on Tracker 2.x while the rest of GNOME Core depends on 3.x. We are working on a solution that means Tracker 2.x miners will only run while Photos the app is running.
So tracker3 will need to be packaged separately to 2.x.
I wish I could have given a definite answer earlier, but obviously we were hoping that the Photos port would be ready.