bug#35551: package gcc does not depend on binutils and glibc

bug#35551: package gcc does not depend on binutils and glibc

[Bruno Haible]

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

bug#35551: package gcc does not depend on binutils and glibc

[Nicolas Goaziou]

Hello,

Bruno Haible <bruno@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

bug#35551: package gcc does not depend on binutils and glibc

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 421 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

bug#35551: package gcc does not depend on binutils and glibc

[Bruno Haible]

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

bug#35551: package gcc does not depend on binutils and glibc

[Ludovic Courtès]

Hi,

Tobias Geerinckx-Rice <me@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’.

bug#35551: package gcc does not depend on binutils and glibc

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 729 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

bug#35551: package gcc does not depend on binutils and glibc

[Bruno Haible]

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

bug#35551: package gcc does not depend on binutils and glibc

[Ricardo Wurmus]

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

> Tobias Geerinckx-Rice <me@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

bug#35551: package gcc does not depend on binutils and glibc

[Bruno Haible]

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

bug#35551: package gcc does not depend on binutils and glibc

[Ricardo Wurmus]

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

bug#35551: package gcc does not depend on binutils and glibc

[Ludovic Courtès]

Hi Bruno,

Bruno Haible <bruno@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’.

bug#35551: guix search

[Bruno Haible]

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

bug#35551: guix search

[Ludovic Courtès]

Hi Bruno,

Bruno Haible <bruno@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’.

bug#35551: guix search

[Bruno Haible]

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

bug#35551: guix search

[Bruno Haible]

> 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

bug#35551: guix search

[Bruno Haible]

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

bug#35551: guix search

[Ludovic Courtès]

Bruno Haible <bruno@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’.

bug#35551: guix search

[znavko]

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@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

bug#35551: guix search

[Ludovic Courtès]

Bruno Haible <bruno@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’.

bug#35551: guix search

[Bruno Haible]

znavko@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

bug#35551: guix search

[Mark H Weaver]

Hi,

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

> Bruno Haible <bruno@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

bug#35551: guix search

[Bruno Haible]

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

bug#35551: guix search

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

bug#35551: guix search

[Mark H Weaver]

Hi Bruno,

Bruno Haible <bruno@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

bug#35551: guix search

[Mark H Weaver]

Hi Tobias,

Tobias Geerinckx-Rice <me@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

bug#35551: guix search

[Ludovic Courtès]

Hi Mark,

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

> Bruno Haible <bruno@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#35551: guix search

[znavko]

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@gnu.org> wrote:

> Hi Mark,
> 
> Mark H Weaver <mhw@netris.org> skribis:
> 
>> Bruno Haible <bruno@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’.