guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: File search


From: antoine . romain . dumont
Subject: Re: File search
Date: Fri, 02 Dec 2022 18:58:42 +0100

Hello Guix!

Guix is top so thanks for the awesome work!

Just to give some feedback on this thread. That's a good news that the
file search functionality in the radar.

> Lately I found myself going several times to
> <https://packages.debian.org> to look for packages providing a given
> file and I thought it’s time to do something about it.

I've finally started to set up my machine with Guix system (and
Guix Home). Finding out where such program or cli is packaged is
definitely something that I need to port my existing use (from mainly
nixified debian or nixos machines) to Guix.

And to answer such question, I used existing "offline" programs in my
machines. I've bounced back and forth between `nix-locate` and `apt-file
search` to determine approximately the packages in Guix (names aren't
usually that different).

Hence, as a user, it's one of my expectation that the Guix cli provides
some equivalent program to lookup from file to package ;).

> The script below creates an SQLite database for the current set of
> packages, but only for those already in the store:
>
>   Guix repl file-database.scm populate
>
> That creates /tmp/db; it took about 25mn on berlin, for 18K packages.
> Then you can run, say:
>
>   Guix repl file-database.scm search boot-9.scm
>
> to find which packages provide a file named ‘boot-9.scm’.  That part is
> instantaneous.
>
> The database for 18K packages is quite big:
>
> --8<---------------cut here---------------start------------->8---
> $ du -h /tmp/db*
> 389M    /tmp/db
> 82M     /tmp/db.gz
> 61M     /tmp/db.zst
> --8<---------------cut here---------------end--------------->8---

For information, in a most recent implementation (@civodul provided me
in #guix-devel), I noticed multiple calls to the indexation step would
duplicate information (at all levels packages, files, directories). So
that might have had an impact in the extracted values above (if ludo had
triggered multiple times the script at the time).

Jsyk, I have started iterating a bit over that provided implementation
(and fixed the current caveat mentioned), added some help message...
I'll follow up with it in a bit (same thread) to have some more feedback
on it.

> How do we expose that information?  There are several criteria I can
> think of: accuracy, freshness, privacy, responsiveness, off-line
> operation.
>
> I think accuracy (making sure you get results that correspond precisely
> to, say, your current channel revisions and your current system) is not
> a high priority: some result is better than no result.

I definitely agree with this. At least from the offline use perspective.
I did not focus at all on the second part of the problematic ("online"
and distribution use).

> Likewise for freshness: results for an older version of a given
> package may still be valid now.

Indeed.

Cheers,
--
tony / Antoine R. Dumont (@ardumont)

-----------------------------------------------------------------
gpg fingerprint BF00 203D 741A C9D5 46A8 BE07 52E2 E984 0D10 C3B8

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]