GNU bug report logs - #35551
package gcc does not depend on binutils and glibc

Previous Next

Package: guix;

Reported by: Bruno Haible <bruno <at> clisp.org>

Date: Fri, 3 May 2019 22:58:01 UTC

Severity: normal

Done: Tobias Geerinckx-Rice <me <at> tobias.gr>

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#35551; Package guix. (Fri, 03 May 2019 22:58:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bruno Haible <bruno <at> clisp.org>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Fri, 03 May 2019 22:58:02 GMT) Full text and rfc822 format available.

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

From: Bruno Haible <bruno <at> clisp.org>
To: bug-guix <at> gnu.org
Subject: package gcc does not depend on binutils and glibc
Date: Sat, 04 May 2019 00:57:26 +0200
Hi,

After installing the guix-1.0 installation image
(guix-system-vm-image-1.0.0.x86_64-linux) and running it with qemu,
I wanted to compile a hello-world program in C.

$ cat hello.c 
#include <stdio.h>
int main () {
  printf("Hello world\n");
  return 0;
}

$ guix install gcc
$ gcc hello.c
error trying to exec 'as': execvp: No such file or directory

Second try:
$ guix install binutils
$ gcc hello.c
/home/guest/.guix-profile/bin/ld: cannot find crt1.o: No such file or directory
/home/guest/.guix-profile/bin/ld: cannot find crt1.o: No such file or directory
collect2: error: ld returned 1 exit status

Third try:
$ guix install glibc
$ gcc hello.c
Now it succeeds!

I would have expected that 'guix install gcc' installs binutils and glibc
as well, because:
  * The use of gcc without binutils is limited: You can use "gcc -E" and "gcc -S"
    to preprocess or compile to .s files, but this is rarely what people need.
  * The use of gcc without glibc is limited: You can use "gcc -c" to compile
    to .o files. But without the ability to create a program or a shared library
    (which needs crti.o rather than crt1.o), the compiler is hardly useful.

Bruno





Information forwarded to bug-guix <at> gnu.org:
bug#35551; Package guix. (Fri, 03 May 2019 23:28:02 GMT) Full text and rfc822 format available.

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

From: Nicolas Goaziou <mail <at> nicolasgoaziou.fr>
To: Bruno Haible <bruno <at> clisp.org>
Cc: 35551 <at> debbugs.gnu.org
Subject: Re: bug#35551: package gcc does not depend on binutils and glibc
Date: Sat, 04 May 2019 01:27:00 +0200
Hello,

Bruno Haible <bruno <at> clisp.org> writes:

> After installing the guix-1.0 installation image
> (guix-system-vm-image-1.0.0.x86_64-linux) and running it with qemu,
> I wanted to compile a hello-world program in C.
>
> $ cat hello.c 
> #include <stdio.h>
> int main () {
>   printf("Hello world\n");
>   return 0;
> }
>
> $ guix install gcc
> $ gcc hello.c
> error trying to exec 'as': execvp: No such file or directory

You are really looking for `gcc-toolchain' package. See section 2.6.6 in
the manual.

HTH,

Regards,

-- 
Nicolas Goaziou




Information forwarded to bug-guix <at> gnu.org:
bug#35551; Package guix. (Sat, 04 May 2019 00:21:02 GMT) Full text and rfc822 format available.

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

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: bug-guix <at> gnu.org
Cc: 35551-done <at> debbugs.gnu.org, Bruno Haible <bruno <at> clisp.org>
Subject: Re: bug#35551: package gcc does not depend on binutils and glibc
Date: Sat, 04 May 2019 02:20:02 +0200
[Message part 1 (text/plain, inline)]
Bruno,

Welcome!

Nicolas Goaziou wrote:
> You are really looking for `gcc-toolchain' package. See section 
> 2.6.6 in
> the manual.

Yup!  :-)

‘Toolchain’ exactly describes what you're looking for, so I'm 
going to go ahead and close this bug.

(Speaking as a user, I'd be annoyed to the point of switching if 
my distro installed ‘binutils’ when asked for ‘gcc’.)

Kind regards,

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

Reply sent to Tobias Geerinckx-Rice <me <at> tobias.gr>:
You have taken responsibility. (Sat, 04 May 2019 00:21:02 GMT) Full text and rfc822 format available.

Notification sent to Bruno Haible <bruno <at> clisp.org>:
bug acknowledged by developer. (Sat, 04 May 2019 00:21:03 GMT) Full text and rfc822 format available.

Information forwarded to bug-guix <at> gnu.org:
bug#35551; Package guix. (Sat, 04 May 2019 01:35:02 GMT) Full text and rfc822 format available.

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

From: Bruno Haible <bruno <at> clisp.org>
To: Tobias Geerinckx-Rice <me <at> tobias.gr>
Cc: 35551-done <at> debbugs.gnu.org, bug-guix <at> gnu.org
Subject: Re: bug#35551: package gcc does not depend on binutils and glibc
Date: Sat, 04 May 2019 03:34:42 +0200
Nicolas Goaziou wrote:
> > You are really looking for `gcc-toolchain' package. See section 
> > 2.6.6 in the manual.

Indeed! Thanks for the answer.

> (Speaking as a user, I'd be annoyed to the point of switching if 
> my distro installed ‘binutils’ when asked for ‘gcc’.)

Well, 'guix install emacs' installs more than emacs as well:
graphviz, ghostscript, python, fftw, cups, ...

There are different kinds of dependencies between packages:
  - Package A contains binaries that are linked to shared libraries
    installed by package B.
  - Package A contains binaries that invoke binaries installed by
    package C.
  - Package A produces output or file formats that can only be viewed
    through package D.
For me, any of these dependencies would be a reason, when installing A,
to install B, C, D as well.

Bruno





Information forwarded to bug-guix <at> gnu.org:
bug#35551; Package guix. (Sat, 04 May 2019 01:36:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-guix <at> gnu.org:
bug#35551; Package guix. (Tue, 07 May 2019 16:05:01 GMT) Full text and rfc822 format available.

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: 35551 <at> debbugs.gnu.org, Ricardo Wurmus <rekado <at> elephly.net>
Cc: me <at> tobias.gr, bruno <at> clisp.org
Subject: Re: bug#35551: package gcc does not depend on binutils and glibc
Date: Tue, 07 May 2019 18:04:13 +0200
Hi,

Tobias Geerinckx-Rice <me <at> tobias.gr> skribis:

> ‘Toolchain’ exactly describes what you're looking for, so I'm going to
> go ahead and close this bug.

True, but we all know that “guix install gcc” is the first thing one
would do, expecting it to actually work.  :-)

Ricardo, I think you had a patch to hide the ‘gcc’ package.  Could you
commit it?

Thanks,
Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#35551; Package guix. (Tue, 07 May 2019 16:24:01 GMT) Full text and rfc822 format available.

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

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: Bruno Haible <bruno <at> clisp.org>
Cc: 35551 <at> debbugs.gnu.org
Subject: Re: bug#35551: package gcc does not depend on binutils and glibc
Date: Tue, 07 May 2019 18:23:24 +0200
[Message part 1 (text/plain, inline)]
Bruno,

Bruno Haible wrote:
>> (Speaking as a user, I'd be annoyed to the point of switching 
>> if 
>> my distro installed ‘binutils’ when asked for ‘gcc’.)
>
> Well, 'guix install emacs' installs more than emacs as well:
> graphviz, ghostscript, python, fftw, cups, ...

Oh, we're talking about different things then.

Installing (in any sense) emacs will add its dependencies to the 
store (your ‘install’), but doesn't propagate them into the 
profile (my ‘install’):

 ~ λ guix environment --pure --ad-hoc emacs
 ~ λ dot
 bash: dot: command not found

I tend to avoid the unqualified term ‘install’ on Guix for this 
reason.  Sorry for the confusion!

Kind regards,

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

Information forwarded to bug-guix <at> gnu.org:
bug#35551; Package guix. (Tue, 07 May 2019 17:28:01 GMT) Full text and rfc822 format available.

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

From: Bruno Haible <bruno <at> clisp.org>
To: Tobias Geerinckx-Rice <me <at> tobias.gr>
Cc: 35551 <at> debbugs.gnu.org
Subject: Re: bug#35551: package gcc does not depend on binutils and glibc
Date: Tue, 07 May 2019 19:26:59 +0200
Tobias Geerinckx-Rice wrote:
> > Well, 'guix install emacs' installs more than emacs as well:
> > graphviz, ghostscript, python, fftw, cups, ...
> 
> Oh, we're talking about different things then.
> 
> Installing (in any sense) emacs will add its dependencies to the 
> store (your ‘install’), but doesn't propagate them into the 
> profile (my ‘install’):
> 
>   ~ λ guix environment --pure --ad-hoc emacs
>   ~ λ dot
>   bash: dot: command not found

After I install 'gcc', I don't really mind whether 'as' and 'ld'
are found in my $PATH. But I want that gcc finds them when gcc
needs to invoke them.

Bruno





Information forwarded to bug-guix <at> gnu.org:
bug#35551; Package guix. (Thu, 09 May 2019 21:23:01 GMT) Full text and rfc822 format available.

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

From: Ricardo Wurmus <rekado <at> elephly.net>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: bruno <at> clisp.org, me <at> tobias.gr, 35551-done <at> debbugs.gnu.org
Subject: Re: bug#35551: package gcc does not depend on binutils and glibc
Date: Thu, 09 May 2019 23:21:52 +0200
Ludovic Courtès <ludo <at> gnu.org> writes:

> Tobias Geerinckx-Rice <me <at> tobias.gr> skribis:
>
>> ‘Toolchain’ exactly describes what you're looking for, so I'm going to
>> go ahead and close this bug.
>
> True, but we all know that “guix install gcc” is the first thing one
> would do, expecting it to actually work.  :-)
>
> Ricardo, I think you had a patch to hide the ‘gcc’ package.  Could you
> commit it?

I’ve just done this.  My apologies for the delay.  Now a search for
“gcc” only returns “gcc-toolchain” (and one “gcc-bootstrap”).

--
Ricardo





Information forwarded to bug-guix <at> gnu.org:
bug#35551; Package guix. (Thu, 09 May 2019 21:58:01 GMT) Full text and rfc822 format available.

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

From: Bruno Haible <bruno <at> clisp.org>
To: Ricardo Wurmus <rekado <at> elephly.net>
Cc: Ludovic Courtès <ludo <at> gnu.org>, me <at> tobias.gr,
 35551-done <at> debbugs.gnu.org
Subject: Re: bug#35551: package gcc does not depend on binutils and glibc
Date: Thu, 09 May 2019 23:57:23 +0200
Hello Ricardo,

> > Ricardo, I think you had a patch to hide the ‘gcc’ package.  Could you
> > commit it?
> 
> I’ve just done this.  My apologies for the delay.  Now a search for
> “gcc” only returns “gcc-toolchain” (and one “gcc-bootstrap”).

Will it also be hidden from the package list
https://www.gnu.org/software/guix/packages/G/ ?

Being a newbie regarding guix, I found it more comfortable to search
for packages under https://www.gnu.org/software/guix/packages/ rather
than through some guix command.

Bruno





Information forwarded to bug-guix <at> gnu.org:
bug#35551; Package guix. (Fri, 10 May 2019 06:20:02 GMT) Full text and rfc822 format available.

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

From: Ricardo Wurmus <rekado <at> elephly.net>
To: Bruno Haible <bruno <at> clisp.org>
Cc: Ludovic Courtès <ludo <at> gnu.org>, me <at> tobias.gr,
 35551-done <at> debbugs.gnu.org
Subject: Re: bug#35551: package gcc does not depend on binutils and glibc
Date: Fri, 10 May 2019 08:18:11 +0200
Hi Bruno,

>> > Ricardo, I think you had a patch to hide the ‘gcc’ package.  Could you
>> > commit it?
>> 
>> I’ve just done this.  My apologies for the delay.  Now a search for
>> “gcc” only returns “gcc-toolchain” (and one “gcc-bootstrap”).
>
> Will it also be hidden from the package list
> https://www.gnu.org/software/guix/packages/G/ ?

It should disappear from the list when it is regenerated, i.e. with the
next release.

-- 
Ricardo





Information forwarded to bug-guix <at> gnu.org:
bug#35551; Package guix. (Fri, 10 May 2019 08:08:02 GMT) Full text and rfc822 format available.

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: Bruno Haible <bruno <at> clisp.org>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, me <at> tobias.gr,
 35551-done <at> debbugs.gnu.org
Subject: Re: bug#35551: package gcc does not depend on binutils and glibc
Date: Fri, 10 May 2019 10:07:24 +0200
Hi Bruno,

Bruno Haible <bruno <at> clisp.org> skribis:

>> > Ricardo, I think you had a patch to hide the ‘gcc’ package.  Could you
>> > commit it?
>> 
>> I’ve just done this.  My apologies for the delay.  Now a search for
>> “gcc” only returns “gcc-toolchain” (and one “gcc-bootstrap”).
>
> Will it also be hidden from the package list
> https://www.gnu.org/software/guix/packages/G/ ?

Yes, when we update it.

> Being a newbie regarding guix, I found it more comfortable to search
> for packages under https://www.gnu.org/software/guix/packages/ rather
> than through some guix command.

Oh, really?

I would hope that ‘guix search’ and ‘guix package --list-available’ are
easier than anything else, and that people value the idea of doing
things locally.  Also, a local search gives the right result while a
remote service might give results for a different Guix revision.

Is there any specific reason why you were uncomfortable with these
commands?  I’m curious how we could improve the user experience here.

Thanks,
Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#35551; Package guix. (Fri, 10 May 2019 09:39:02 GMT) Full text and rfc822 format available.

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

From: Bruno Haible <bruno <at> clisp.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, me <at> tobias.gr,
 35551-done <at> debbugs.gnu.org
Subject: Re: guix search
Date: Fri, 10 May 2019 11:38:31 +0200
Hi Ludo,

> I would hope that ‘guix search’ and ‘guix package --list-available’ are
> easier than anything else, and that people value the idea of doing
> things locally.  Also, a local search gives the right result while a
> remote service might give results for a different Guix revision.
> 
> Is there any specific reason why you were uncomfortable with these
> commands?  I’m curious how we could improve the user experience here.

Yes. I was looking for a package that contains the 'ssh' command.
$ guix search ssh | less
returns libssh, libssh2, guile2.0-ssh, guile-ssh, sshpass, ...,
emacs-counsel-tramp.
The answer I was looking for was 'openssh', but it was hidden
among 66 packages.

A search is good if the relevant results for the user occur
among the first screen.

Possible improvements include:

1) If the search term is X and installing the package would cause
   a program named X to appear in $PATH, then list this package first.

   This rule would have listed 'openssh' first. Also, for 'guix search gcc',
   it would now make 'gcc-toolchain' appear first (right?).

2) Another heuristic for presenting the "best" hits first:
   Sort the graph of the packages (using dependencies as graph edges).
   Then present the "base" packages (the packages which don't depend on
   other packages) first.

   This will likely make packages that are bindings (guile-ssh, ruby-net-ssh,
   etc.) appear after openssh.

3) If the resulting list is longer than one screenful, present only the
   names, not names + details. Like
     $ guix search ssh | grep '^name:'
   would do.
   Even without the improvements 1) and 2), the command
     $ guix search ssh | grep '^name:' | grep ssh | sort
   produces a one-screenful result that I could have evaluated in 10 seconds.

Bruno





Information forwarded to bug-guix <at> gnu.org:
bug#35551; Package guix. (Fri, 10 May 2019 10:18:02 GMT) Full text and rfc822 format available.

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: Bruno Haible <bruno <at> clisp.org>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, me <at> tobias.gr,
 35551-done <at> debbugs.gnu.org
Subject: Re: guix search
Date: Fri, 10 May 2019 12:17:30 +0200
Hi Bruno,

Bruno Haible <bruno <at> clisp.org> skribis:

>> I would hope that ‘guix search’ and ‘guix package --list-available’ are
>> easier than anything else, and that people value the idea of doing
>> things locally.  Also, a local search gives the right result while a
>> remote service might give results for a different Guix revision.
>> 
>> Is there any specific reason why you were uncomfortable with these
>> commands?  I’m curious how we could improve the user experience here.
>
> Yes. I was looking for a package that contains the 'ssh' command.
> $ guix search ssh | less
> returns libssh, libssh2, guile2.0-ssh, guile-ssh, sshpass, ...,
> emacs-counsel-tramp.
> The answer I was looking for was 'openssh', but it was hidden
> among 66 packages.

I see.

> A search is good if the relevant results for the user occur
> among the first screen.
>
> Possible improvements include:
>
> 1) If the search term is X and installing the package would cause
>    a program named X to appear in $PATH, then list this package first.
>
>    This rule would have listed 'openssh' first. Also, for 'guix search gcc',
>    it would now make 'gcc-toolchain' appear first (right?).

I agree that this would be great, but we don’t know beforehand what
commands a package provides.  For that we’d need to resort to an
external service providing this info.

> 2) Another heuristic for presenting the "best" hits first:
>    Sort the graph of the packages (using dependencies as graph edges).
>    Then present the "base" packages (the packages which don't depend on
>    other packages) first.
>
>    This will likely make packages that are bindings (guile-ssh, ruby-net-ssh,
>    etc.) appear after openssh.

This sounds like an interesting option, at least when one is searching
for an application and not for a library.

> 3) If the resulting list is longer than one screenful, present only the
>    names, not names + details. Like
>      $ guix search ssh | grep '^name:'
>    would do.
>    Even without the improvements 1) and 2), the command
>      $ guix search ssh | grep '^name:' | grep ssh | sort
>    produces a one-screenful result that I could have evaluated in 10 seconds.

OK, though you would have been unable to see the descriptions.

Another option I thought of would be to display only the 10 results with
the highest relevance by default, when stdout is a terminal.

Thoughts?

Thanks,
Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#35551; Package guix. (Fri, 10 May 2019 10:19:03 GMT) Full text and rfc822 format available.

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

From: Bruno Haible <bruno <at> clisp.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, me <at> tobias.gr,
 35551-done <at> debbugs.gnu.org
Subject: Re: guix search
Date: Fri, 10 May 2019 12:18:48 +0200
I wrote:
> 1) If the search term is X and installing the package would cause
>    a program named X to appear in $PATH, then list this package first.

More precisely: If there is a package named X (perfect match), it should
come first. The packages that install a program named X should come second.

Bruno





Information forwarded to bug-guix <at> gnu.org:
bug#35551; Package guix. (Fri, 10 May 2019 10:23:02 GMT) Full text and rfc822 format available.

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

From: Bruno Haible <bruno <at> clisp.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, me <at> tobias.gr,
 35551-done <at> debbugs.gnu.org
Subject: Re: guix search
Date: Fri, 10 May 2019 12:22:16 +0200
> Another option I thought of would be to display only the 10 results with
> the highest relevance by default, when stdout is a terminal.

That would be OK as a second step. But first, we should get the
sort order (the notion of relevance) improved.

Bruno





Information forwarded to bug-guix <at> gnu.org:
bug#35551; Package guix. (Fri, 10 May 2019 14:22:02 GMT) Full text and rfc822 format available.

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

From: Bruno Haible <bruno <at> clisp.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, me <at> tobias.gr,
 35551-done <at> debbugs.gnu.org
Subject: Re: guix search
Date: Fri, 10 May 2019 16:21:21 +0200
Hi Ludo,

> we don’t know beforehand what commands a package provides.

Indeed, this information becomes available only while/after
a package is built.

> For that we’d need to resort to an external service providing this info.

Why would it need to be an external service? Can't you incorporate
this information in a data file that you ship as part of the
distribution?

Bruno







Information forwarded to bug-guix <at> gnu.org:
bug#35551; Package guix. (Fri, 10 May 2019 15:18:02 GMT) Full text and rfc822 format available.

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: Bruno Haible <bruno <at> clisp.org>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, me <at> tobias.gr,
 35551-done <at> debbugs.gnu.org
Subject: Re: guix search
Date: Fri, 10 May 2019 17:17:29 +0200
Bruno Haible <bruno <at> clisp.org> skribis:

>> Another option I thought of would be to display only the 10 results with
>> the highest relevance by default, when stdout is a terminal.
>
> That would be OK as a second step. But first, we should get the
> sort order (the notion of relevance) improved.

It’s tricky to map our intuition to actual metrics on the data that we
have, though.

The current metrics used to compute the relevance score are here:

  https://git.savannah.gnu.org/cgit/guix.git/tree/guix/ui.scm#n1406

Like I said, command names are not available in an off-line context.

Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#35551; Package guix. (Fri, 10 May 2019 15:44:01 GMT) Full text and rfc822 format available.

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

From: znavko <at> disroot.org
To: "Bruno Haible" <bruno <at> clisp.org>,
 "Ludovic Courtès" <ludo <at> gnu.org>
Cc: 35551-done <at> debbugs.gnu.org
Subject: Re: bug#35551: guix search
Date: Fri, 10 May 2019 15:43:17 +0000
Hello!

$ guix search video
shows: vidstab, youtube-viewer, ffmpegthumbnailer, xf86-video-mach64...
I'd better prefer this sorting:
vlc, mpv, gnome-mpv, blender, avidemux, kdenlive...

To do so need to sort by popularity, using f.e. fsf site statistics.
There is no other mathematics methods like 'if this package provides ssh command in path'.
The other way is to add own 'Relevance' field and to fill it manually or using some statistic reasons.


May 10, 2019 10:23 AM, "Bruno Haible" <bruno <at> clisp.org> wrote:

>> Another option I thought of would be to display only the 10 results with
>> the highest relevance by default, when stdout is a terminal.
> 
> That would be OK as a second step. But first, we should get the
> sort order (the notion of relevance) improved.
> 
> Bruno




Information forwarded to bug-guix <at> gnu.org:
bug#35551; Package guix. (Fri, 10 May 2019 21:16:02 GMT) Full text and rfc822 format available.

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: Bruno Haible <bruno <at> clisp.org>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, me <at> tobias.gr,
 35551-done <at> debbugs.gnu.org
Subject: Re: guix search
Date: Fri, 10 May 2019 23:15:21 +0200
Bruno Haible <bruno <at> clisp.org> skribis:

>> For that we’d need to resort to an external service providing this info.
>
> Why would it need to be an external service? Can't you incorporate
> this information in a data file that you ship as part of the
> distribution?

Such a file would quickly become stale, it’d have to be updated from an
external service anyway.

Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#35551; Package guix. (Fri, 10 May 2019 21:23:01 GMT) Full text and rfc822 format available.

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

From: Bruno Haible <bruno <at> clisp.org>
To: znavko <at> disroot.org
Cc: Ludovic Courtès <ludo <at> gnu.org>,
 35551-done <at> debbugs.gnu.org
Subject: Re: bug#35551: guix search
Date: Fri, 10 May 2019 23:22:45 +0200
znavko <at> disroot.org wrote:
> $ guix search video
> shows: vidstab, youtube-viewer, ffmpegthumbnailer, xf86-video-mach64...
> I'd better prefer this sorting:
> vlc, mpv, gnome-mpv, blender, avidemux, kdenlive...
> 
> To do so need to sort by popularity, using f.e. fsf site statistics.

+1.

This approach would work with many more packages than the algorithmic
approaches that I had suggested.

Bruno





Information forwarded to bug-guix <at> gnu.org:
bug#35551; Package guix. (Fri, 10 May 2019 22:07:02 GMT) Full text and rfc822 format available.

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

From: Mark H Weaver <mhw <at> netris.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 35551-done <at> debbugs.gnu.org, Bruno Haible <bruno <at> clisp.org>
Subject: Re: bug#35551: guix search
Date: Fri, 10 May 2019 18:04:44 -0400
Hi,

Ludovic Courtès <ludo <at> gnu.org> writes:

> Bruno Haible <bruno <at> clisp.org> skribis:
>
>>> For that we’d need to resort to an external service providing this info.
>>
>> Why would it need to be an external service? Can't you incorporate
>> this information in a data file that you ship as part of the
>> distribution?
>
> Such a file would quickly become stale, it’d have to be updated from an
> external service anyway.

If we add functionality that calls out to the network in response to a
package search, e.g. to query popularity ratings or package file
listings, we should make sure the user knows it's happening, and provide
a way to disable it.  Some users may not want information about their
package searches to be leaked to the outside world.

     Thanks,
       Mark




Information forwarded to bug-guix <at> gnu.org:
bug#35551; Package guix. (Fri, 10 May 2019 22:39:02 GMT) Full text and rfc822 format available.

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

From: Bruno Haible <bruno <at> clisp.org>
To: Mark H Weaver <mhw <at> netris.org>
Cc: Ludovic Courtès <ludo <at> gnu.org>,
 35551-done <at> debbugs.gnu.org
Subject: Re: bug#35551: guix search
Date: Sat, 11 May 2019 00:38:41 +0200
Mark H Weaver wrote:
> If we add functionality that calls out to the network in response to a
> package search, e.g. to query popularity ratings or package file
> listings, we should make sure the user knows it's happening, and provide
> a way to disable it.  Some users may not want information about their
> package searches to be leaked to the outside world.

Good point.

Would it be more acceptable, upon 'guix search', to download an incremental
update of a package popularity database, and do the search locally? This
way, only the fact that the user has been doing a 'guix search' would be
leaked to the outside world, not the search term.

Bruno





Information forwarded to bug-guix <at> gnu.org:
bug#35551; Package guix. (Fri, 10 May 2019 23:42:01 GMT) Full text and rfc822 format available.

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

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: Bruno Haible <bruno <at> clisp.org>
Cc: Mark H Weaver <mhw <at> netris.org>, 35551-done <at> debbugs.gnu.org
Subject: Re: bug#35551: guix search
Date: Sat, 11 May 2019 01:41:31 +0200
[Message part 1 (text/plain, inline)]
Bruno Haible wrote:
> Mark H Weaver wrote:
>> If we add functionality that calls out to the network in 
>> response to a
>> package search, e.g. to query popularity ratings or package 
>> file
>> listings, we should make sure the user knows it's happening, 
>> and provide
>> a way to disable it.  Some users may not want information about 
>> their
>> package searches to be leaked to the outside world.
>
> Good point.
>
> Would it be more acceptable, upon 'guix search', to download an 
> incremental
> update of a package popularity database, and do the search 
> locally? This
> way, only the fact that the user has been doing a 'guix search' 
> would be
> leaked to the outside world, not the search term.

I don't think Mark intended to present it as a good idea at all… 
;-)

Popularity is irrelevant to search relevance.

Kind regards,

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

Information forwarded to bug-guix <at> gnu.org:
bug#35551; Package guix. (Sat, 11 May 2019 18:21:02 GMT) Full text and rfc822 format available.

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

From: Mark H Weaver <mhw <at> netris.org>
To: Bruno Haible <bruno <at> clisp.org>
Cc: 35551-done <at> debbugs.gnu.org
Subject: Re: bug#35551: guix search
Date: Sat, 11 May 2019 14:18:27 -0400
Hi Bruno,

Bruno Haible <bruno <at> clisp.org> writes:

> Mark H Weaver wrote:
>> If we add functionality that calls out to the network in response to a
>> package search, e.g. to query popularity ratings or package file
>> listings, we should make sure the user knows it's happening, and provide
>> a way to disable it.  Some users may not want information about their
>> package searches to be leaked to the outside world.
>
> Good point.
>
> Would it be more acceptable, upon 'guix search', to download an incremental
> update of a package popularity database, and do the search locally? This
> way, only the fact that the user has been doing a 'guix search' would be
> leaked to the outside world, not the search term.

Yes, that would address my concerns, although popularity ratings might
be compact enough and change slowly enough that it might be sufficient
to simply have them embedded in the Guix source code and manually
updated periodically.

Popularity ratings would also be useful to set build priorities on our
build farms.

The package file listings, on the other hand, are likely to be so large
that it's not practical to download an incremental update of all of
them.

      Thanks,
        Mark




Information forwarded to bug-guix <at> gnu.org:
bug#35551; Package guix. (Sat, 11 May 2019 18:41:01 GMT) Full text and rfc822 format available.

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

From: Mark H Weaver <mhw <at> netris.org>
To: Tobias Geerinckx-Rice <me <at> tobias.gr>
Cc: 35551-done <at> debbugs.gnu.org, Bruno Haible <bruno <at> clisp.org>
Subject: Re: bug#35551: guix search
Date: Sat, 11 May 2019 14:38:26 -0400
Hi Tobias,

Tobias Geerinckx-Rice <me <at> tobias.gr> writes:

> Bruno Haible wrote:
>> Mark H Weaver wrote:
>>> If we add functionality that calls out to the network in response
>>> to a
>>> package search, e.g. to query popularity ratings or package file
>>> listings, we should make sure the user knows it's happening, and
>>> provide
>>> a way to disable it.  Some users may not want information about
>>> their
>>> package searches to be leaked to the outside world.
>>
>> Good point.
>>
>> Would it be more acceptable, upon 'guix search', to download an
>> incremental
>> update of a package popularity database, and do the search locally?
>> This
>> way, only the fact that the user has been doing a 'guix search'
>> would be
>> leaked to the outside world, not the search term.
>
> I don't think Mark intended to present it as a good idea at all… ;-)

I'm not sure what you're suggesting here.  While I have some privacy
concerns, I'm not generally opposed to these ideas.

> Popularity is irrelevant to search relevance.

I agree that ideally, popularity shouldn't be relevant for searches.  If
we could apply sufficient intelligence to understand what the user is
looking for, and sufficient knowledge of our packages to determine which
ones meet those requirements, it would be best to ignore popularity.

However, given the severe limitations of the intelligence we can apply
to this problem, making use of popularity is an easy approach that tends
to work fairly well in practice.

Keep in mind that Google became dominant in the search market largely
because of the success of their PageRank algorithm, which essentially
orders results by popularity, although with greater weight given to the
opinions of those who are themselves popular.  It clearly works well.

What do you think?

    Regards,
      Mark




Information forwarded to bug-guix <at> gnu.org:
bug#35551; Package guix. (Mon, 13 May 2019 07:58:01 GMT) Full text and rfc822 format available.

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: Mark H Weaver <mhw <at> netris.org>
Cc: 35551-done <at> debbugs.gnu.org, Bruno Haible <bruno <at> clisp.org>
Subject: Re: bug#35551: guix search
Date: Mon, 13 May 2019 09:57:50 +0200
Hi Mark,

Mark H Weaver <mhw <at> netris.org> skribis:

> Bruno Haible <bruno <at> clisp.org> writes:
>
>> Mark H Weaver wrote:
>>> If we add functionality that calls out to the network in response to a
>>> package search, e.g. to query popularity ratings or package file
>>> listings, we should make sure the user knows it's happening, and provide
>>> a way to disable it.  Some users may not want information about their
>>> package searches to be leaked to the outside world.
>>
>> Good point.
>>
>> Would it be more acceptable, upon 'guix search', to download an incremental
>> update of a package popularity database, and do the search locally? This
>> way, only the fact that the user has been doing a 'guix search' would be
>> leaked to the outside world, not the search term.
>
> Yes, that would address my concerns, although popularity ratings might
> be compact enough and change slowly enough that it might be sufficient
> to simply have them embedded in the Guix source code and manually
> updated periodically.
>
> Popularity ratings would also be useful to set build priorities on our
> build farms.
>
> The package file listings, on the other hand, are likely to be so large
> that it's not practical to download an incremental update of all of
> them.

FWIW, I like that there’s a purely off-line mode for ‘guix search’, as
is currently the case (after all, none of Guix relies on any single
service so far, and I think that’s a nice property.)

However, I think it’d be nice to have the option to enhance search
results by resorting to external services—just like using a substitute
service “enhances” the user experience.

I agree that the approach should rather be to download a complete
database and operate locally on it, rather than give the exact query to
the server.

Thanks,
Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#35551; Package guix. (Mon, 13 May 2019 15:40:01 GMT) Full text and rfc822 format available.

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

From: znavko <at> disroot.org
To: "Ludovic Courtès" <ludo <at> gnu.org>, "Mark H Weaver"
 <mhw <at> netris.org>
Cc: 35551-done <at> debbugs.gnu.org, Bruno Haible <bruno <at> clisp.org>
Subject: Re: bug#35551: guix search
Date: Mon, 13 May 2019 15:39:29 +0000
Thank you, Ludovic. It will be nice to have some additional fields computed with Internet databases like:

Tag->name
Tag->Relevance
Purpose: editor, viewer, library, development tool
Interface: gui app, console-only, console and gui, system calls

For every tag needs to determine relevance.
For example, package VLC:
Tag->name: video
Tag->relevance: 100
Tag->name: view
Tag->relevance: 90
and other tags
Purpose: viewer
Interface: gui app

This can give additional options for search or just improve sorting when user type f.e. ' guix search video viewer'


May 13, 2019 7:58 AM, "Ludovic Courtès" <ludo <at> gnu.org> wrote:

> Hi Mark,
> 
> Mark H Weaver <mhw <at> netris.org> skribis:
> 
>> Bruno Haible <bruno <at> clisp.org> writes:
>> 
>>> Mark H Weaver wrote:
>> 
>> If we add functionality that calls out to the network in response to a
>> package search, e.g. to query popularity ratings or package file
>> listings, we should make sure the user knows it's happening, and provide
>> a way to disable it. Some users may not want information about their
>> package searches to be leaked to the outside world.
>>> Good point.
>>> 
>>> Would it be more acceptable, upon 'guix search', to download an incremental
>>> update of a package popularity database, and do the search locally? This
>>> way, only the fact that the user has been doing a 'guix search' would be
>>> leaked to the outside world, not the search term.
>> 
>> Yes, that would address my concerns, although popularity ratings might
>> be compact enough and change slowly enough that it might be sufficient
>> to simply have them embedded in the Guix source code and manually
>> updated periodically.
>> 
>> Popularity ratings would also be useful to set build priorities on our
>> build farms.
>> 
>> The package file listings, on the other hand, are likely to be so large
>> that it's not practical to download an incremental update of all of
>> them.
> 
> FWIW, I like that there’s a purely off-line mode for ‘guix search’, as
> is currently the case (after all, none of Guix relies on any single
> service so far, and I think that’s a nice property.)
> 
> However, I think it’d be nice to have the option to enhance search
> results by resorting to external services—just like using a substitute
> service “enhances” the user experience.
> 
> I agree that the approach should rather be to download a complete
> database and operate locally on it, rather than give the exact query to
> the server.
> 
> Thanks,
> Ludo’.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 11 Jun 2019 11:24:08 GMT) Full text and rfc822 format available.

This bug report was last modified 4 years and 293 days ago.

Previous Next


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