Something I hit many times with emerge is when I have a typo when trying to emerge something, for example: emerge qtplot -> it fails and, then, it starts to search for similar packages for a long long time. On the other hand using "eix --fuzzy qtplot" is near instantaneous... wouldn't be possible to "soft depend" on eix when it's available to try to use it as a first option and, only if not present, fallback to the current (and slower) portage implementation for that? Thanks a lot!
Maybe we should just have a default post-sync hook that calls `emaint --update-pkg-desc-index`, so emerge's search function isn't so slow by default.
Also, we need to make portage's similar_name_search function use IndexedPortdb and IndexedVardb when search indexing is enabled.
I've had a postsync hook running to do that for each repo since you added the indexed search. I'll submit it for review.
Created attachment 408368 [details] /etc/portage/repo.postsync.d script This script I've been using to update the search index on a per repo basis. Zac, only thing more I think we should do is split off the postsync tasks and not wait before moving on. For these search index updates, it would speed things up for larger overlays like the kde one.
There's a patch in the following branch: https://github.com/zmedico/portage/tree/bug_556764 You can test it like this: echo '=sys-apps/portage-9999 **' >> /etc/portage/package.accept_keywords portage_LIVE_BRANCH=bug_556764 \ portage_LIVE_REPO=https://github.com/zmedico/portage.git \ emerge -1 =sys-apps/portage-9999 I've posted it for review here: https://archives.gentoo.org/gentoo-portage-dev/message/ba234d5a3efb9ef707a4497022475800
This is in the master branch now: https://gitweb.gentoo.org/proj/portage.git/commit/?id=b7149002bf23889f280c502afe6ceda0b1345ca3 (In reply to Brian Dolbec from comment #4) > Created attachment 408368 [details] > /etc/portage/repo.postsync.d script > > This script I've been using to update the search index on a per repo basis. > > Zac, only thing more I think we should do is split off the postsync tasks > and not wait before moving on. For these search index updates, it would > speed things up for larger overlays like the kde one. If we're doing things concurrently, maybe we should be syncing multiple repos in parallel.
(In reply to Zac Medico from comment #6) > This is in the master branch now: > > https://gitweb.gentoo.org/proj/portage.git/commit/ > ?id=b7149002bf23889f280c502afe6ceda0b1345ca3 > > (In reply to Brian Dolbec from comment #4) > > Created attachment 408368 [details] > > /etc/portage/repo.postsync.d script > > > > This script I've been using to update the search index on a per repo basis. > > > > Zac, only thing more I think we should do is split off the postsync tasks > > and not wait before moving on. For these search index updates, it would > > speed things up for larger overlays like the kde one. > > If we're doing things concurrently, maybe we should be syncing multiple > repos in parallel. I've filed bug 557426 for this, and posted a patch.
(In reply to Brian Dolbec from comment #4) > Created attachment 408368 [details] > /etc/portage/repo.postsync.d script > > This script I've been using to update the search index on a per repo basis. > > Zac, only thing more I think we should do is split off the postsync tasks > and not wait before moving on. For these search index updates, it would > speed things up for larger overlays like the kde one. Now that parallel sync is supported is merged (bug 557426), maybe we should have portage install this repo.postsync.d script?
/etc/portage/repo.postsync.d/example
Released in portage-2.2.21 Sorry, my copy buffer changed on me without me realizing.
