| sitter |
Update-apt-xapian-index is organised in plugins, each representing a
data source for the index. Each of them reports a timestamp of the
latest change, and the updated index takes the maximum of them as its
own timestamp.
We were checking the time of Dir::State::status
(/var/lib/dpkg/status), which is not used in any plugin. When it was
newer than all data sources, we would continuously see the index as out
of date.
BUG: 390476
| Automatic diff as part of commit; lint not applicable. |
| Automatic diff as part of commit; unit tests not applicable. |
Git tells that the check was introduced in e70a781e (2010-09-25)
"Also check to see if the dpkg status file is newer than the xapian index, so that we can catch new packages installed directly via dpkg"
I couldn't find any reference to dpkg in axi plugins, so I'm not sure this check makes any sense for the index. An alternative would be to skip the timestamp check entirely, just start the update (without --force), and let axi decide whether it has something to do. But this call is over DBus and starts a new process (update-axi), and we (Muon) might be calling it more often than expected (i.e. every time we update the status bar?).
And this function Backend::xapianIndexNeedsUpdate becomes meaningless, it would just check if the index exists.
Therefore, I'm happy to check just the cache.
I don't know enough about xapian to say if that makes sense. But the way I read the original commit is that if you were to install a package through dpkg directly, xapian would not know about it until you force a cache refresh (which in turn would refresh the cache from apt and apt in that case is simply a frontend for dpkg).
I suppose a way to test this is to install atom or discord through their binary blob debs via dpkg -i. That should show you the problem Jonathan solved originally. I expect the package would simply not show up in a search until you force an update to xapian.
All that said, I expect it is nontrivial to prevent the time stamps between dpkg and xapian to sometimes yield false positives and TBH installing stuff via dpkg is a fairly obsolete method to install debs since apt install accept local files nowadays. So, it's probably fine to land. If it causes a regression I am sure someone will complain. From where I am standing checking apt covers 99.9% of all modern use cases.