GNU bug report logs - #30130
Add ‘guix whereis’ command

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 30130 in the body.
You can then email your comments to 30130 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Lirzin <mthl <at> gnu.org>
To: bug-guix <at> gnu.org
Subject: Add ‘guix whereis’ command
Date: Mon, 15 Jan 2018 18:16:11 +0100

Hello,

I would find really useful if Guix was providing a tool similar to what
‘dnf whatprovides’ or ‘apt-file’ does.  I mean something to check what
packages provides a particular file (executable/manual/library).

My main use-case is when running a ‘configure’ script which checks an
arbitrary program, I would like ‘guix whereis’ to help me find out what
package I need to install to satisfy its configuration requirement.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Message #10 received at 30130 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Mathieu Lirzin <mthl <at> gnu.org>
Cc: 30130 <at> debbugs.gnu.org
Subject: Re: bug#30130: Add ‘guix whereis’ command
Date: Wed, 17 Jan 2018 15:05:42 +0100

Mathieu Lirzin <mthl <at> gnu.org> skribis:

> I would find really useful if Guix was providing a tool similar to what
> ‘dnf whatprovides’ or ‘apt-file’ does.  I mean something to check what
> packages provides a particular file (executable/manual/library).

This has been discussed before, and can be summarized this way:

  1. Finding files that are already in your store could be done easily,
     using ‘updatedb’ or something similar.

  2. Finding files from packages not in your store is trickier: it
     involves getting info from a build farm server typically.

If we address #1 in a Guix-specific way (automatically populating a file
database upon build completion), then perhaps we could arrange for ‘guix
publish’ to publish that info.

Ludo’.

Message #13 received at 30130 <at> debbugs.gnu.org (full text, mbox):

From: swedebugia <at> riseup.net
To: 30130 <at> debbugs.gnu.org
Subject: Add ‘guix whereis’ command
Date: Mon, 17 Dec 2018 01:39:08 -0800

Hi

This could be solved by a new field in the package-record: (provides
'("list of commands provided"))

What do you think?

This could allow us to quickly let guile search the list of provided
commands and return the package name.

E.g. right now in my guixsd I have no "file" command. I have no idea
which package installs it. :p

-- 
Cheers 
Swedebugia

Message #16 received at 30130 <at> debbugs.gnu.org (full text, mbox):

From: Ricardo Wurmus <rekado <at> elephly.net>
To: swedebugia <at> riseup.net
Cc: 30130 <at> debbugs.gnu.org
Subject: Re: bug#30130: Add ‘guix whereis’ command
Date: Mon, 17 Dec 2018 13:03:38 +0100

> This could be solved by a new field in the package-record: (provides
> '("list of commands provided"))

The danger with doing this in a package definition is that it can easily
go out of sync unless we also add a verification phase to compare the
output with the list of provided executables.  Another problem is that
the list might not be complete and it is yet another manual thing to
maintain for all packages.

Another approach is to shift this task to substitute servers.

> E.g. right now in my guixsd I have no "file" command. I have no idea
> which package installs it. :p

The confusingly named “file” package provides the “file” executable ;)

--
Ricardo

Message #19 received at 30130 <at> debbugs.gnu.org (full text, mbox):

From: Efraim Flashner <efraim <at> flashner.co.il>
To: Ricardo Wurmus <rekado <at> elephly.net>
Cc: swedebugia <at> riseup.net, 30130 <at> debbugs.gnu.org
Subject: Re: bug#30130: Add ‘guix whereis’
 command
Date: Mon, 17 Dec 2018 22:55:47 +0200

[Message part 1 (text/plain, inline)]

On Mon, Dec 17, 2018 at 01:03:38PM +0100, Ricardo Wurmus wrote:
> 
> > This could be solved by a new field in the package-record: (provides
> > '("list of commands provided"))
> 
> The danger with doing this in a package definition is that it can easily
> go out of sync unless we also add a verification phase to compare the
> output with the list of provided executables.  Another problem is that
> the list might not be complete and it is yet another manual thing to
> maintain for all packages.
> 
> Another approach is to shift this task to substitute servers.

This is Debian's aproach, with 'apt-file'. Another option that would
keep it more local would be a custom updatedb command that would look in
bin/sbin/libexec in the store for binaries and keep track of that. The
downside of course being that you'd only know about binaries you had in
your store.

> 
> > E.g. right now in my guixsd I have no "file" command. I have no idea
> > which package installs it. :p
> 
> The confusingly named “file” package provides the “file” executable ;)

This works for file, but it's not obvious that 'clear' is in ncurses.

-- 
Efraim Flashner   <efraim <at> flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[signature.asc (application/pgp-signature, inline)]

Message #24 received at 30130-done <at> debbugs.gnu.org (full text, mbox):

From: Ricardo Wurmus <rekado <at> elephly.net>
To: 30130-done <at> debbugs.gnu.org
Subject: Add ‘guix whereis’ command
Date: Tue, 30 Jan 2024 17:13:32 +0100

I’m closing this because we now have “guix locate”.

-- 
Ricardo

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.