zimoun <zimon.touto...@gmail.com> writes: > I am not sure to see how. One needs all the database to search inside > and cannot know in advance which packages etc.. Contrary to “guix size” > which manipulates the graph and then download the missing parts. > > Therefore, your suggestion is to download all the database the first > time the user run “guix filesearch”, i.e., download ~10MiB.
Yes. If the user is not using substitutes, they can also compute the database from their local store items (like I'm doing in the graft). It's less useful but still a bit more convenient than running find/locate on /gnu/store. > Then each time the user runs “guix pull” then “guix filesearch”, two > options, either download the new database for this last Guix generation, > or either download a diff (not sure the complexity is worth for ~10MiB). > > Right? Yes. > And what about the channels? Because if I read correctly, “guix size” > fails when “no available substitute information“. Just like `guix size', it would work with local items. But if there is no substitute server for channels, then there is no way around it. >> I think this is a bit beyond the scope of this patch set. I'd rather >> focus on files exclusively for now and proceed one step at a time :) > > I do not think it is beyond the scope because Arun introduced an SQLite > database for improving “guix search”. But this path had been stopped > because of “introducing complexity” [1]. Therefore, if “guix > filesearch” introduces a SQL cache, then it seems a good idea to be also > usable by “guix search”. > > Well, if the table is extended with the fields “synopsis” and > “description” then what is the size of the database? Does it kill the > lookup performance? Good point, I'll test and report my measures. Cheers! -- Pierre Neidhardt https://ambrevar.xyz/
signature.asc
Description: PGP signature
