Bugzilla – Bug 985821
software.opensuse.org package search uses stale index
Last modified: 2018-12-14 18:50:13 UTC
For example: https://software.opensuse.org/package/gnome-shell Expand Tumbleweed tab and note the version 3.6.3, which is obviously not true. Another example: https://software.opensuse.org/package/sssd
Confirmed. If you go to https://software.opensuse.org/package/openssl, the link "openSUSE Leap 42.1" > "Official update" points to https://build.opensuse.org/package/show?project=openSUSE%3ALeap%3A42.1%3AUpdate&package=patchinfo.4769, which is two patches behind, the current one being 5667. Since patch 5050 wasn't indexed, that would indicate that the index is (partially perhaps) at least 5 months old.
I'm sorry, but I don't know why this bug is assigned to me. Re-assigning to our top committer in the github repository: coolo
The binary search index is maintained within OBS - software.oo is just the interface to it
Commenting on this because because is the flip side to the original submit (>2 years ago so don't know if the original bug still exists or is relevant). For a long time now and currently, https://software.opensuse.org/search Has been extremely slow. Suggests that results are not cached <and> especially if search engine is based on either Elastic(I think may be the case) or the Hadoop stack, badly needs optimizing(My guess likely) or additional resources(always necessary to provide minimum at least). The "indexing" mentioned in the @OP is likely a red herring although remains an outside possibility because IMO if using Elastic or Hadoop, actual indexing is likely fairly obvious (not likely need beyond what is obvious) and decent performance should be easy to obtain... eg even 4-8 dirt cheap machines for worker nodes. The current implementation performs as though it's a single cheap machine (eg quad or duo core processor only) with only minimum nodes configured... Perhaps even sharing functionality with the website itself. Elastic and Hadoop don't necessarily need a lot of hardware, just the ability to support more concurrent threads. Just saying... for probably less than $2000(or even half that) it would probably be possible to grab some old machines off a garbage/recycle heap and likely solve the performance problems (don't spend extra when for an architecture that supports deployment and expansion on cheap nodes)