package gcc does not depend on binutils and glibc

  • Done
  • quality assurance status badge
Details
7 participants
  • Bruno Haible
  • Ludovic Courtès
  • Nicolas Goaziou
  • Tobias Geerinckx-Rice
  • Mark H Weaver
  • Ricardo Wurmus
  • znavko
Owner
unassigned
Submitted by
Bruno Haible
Severity
normal
B
B
Bruno Haible wrote on 4 May 2019 00:57
(address . bug-guix@gnu.org)
1666426.mZ6LCf6Yd0@omega
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
N
N
Nicolas Goaziou wrote on 4 May 2019 01:27
(name . Bruno Haible)(address . bruno@clisp.org)(address . 35551@debbugs.gnu.org)
87imurunjv.fsf@nicolasgoaziou.fr
Hello,

Bruno Haible <bruno@clisp.org> writes:

Toggle quote (15 lines)
> 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
T
T
Tobias Geerinckx-Rice wrote on 4 May 2019 02:20
(address . bug-guix@gnu.org)
8736lvf4ul.fsf@nckx
Bruno,

Welcome!

Nicolas Goaziou wrote:
Toggle quote (4 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQT12iAyS4c9C3o4dnINsP+IT1VteQUCXMzasgAKCRANsP+IT1Vt
eTbRAQC251jYKwidZn/EtE3e2XUP7CL8m0ipNXG5Io4Fvzj10gEA3el1qQMX0KqU
DzhsROZCDKr8W90EEZMXitDqnnMc+gE=
=d/Pc
-----END PGP SIGNATURE-----

B
B
Bruno Haible wrote on 4 May 2019 03:34
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)
3104507.Mr5onzjcma@omega
Nicolas Goaziou wrote:
Toggle quote (3 lines)
> > You are really looking for `gcc-toolchain' package. See section
> > 2.6.6 in the manual.

Indeed! Thanks for the answer.

Toggle quote (3 lines)
> (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
Closed
L
L
Ludovic Courtès wrote on 7 May 2019 18:04
87y33i2qv6.fsf@gnu.org
Hi,

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

Toggle quote (3 lines)
> ‘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’.
T
T
Tobias Geerinckx-Rice wrote on 7 May 2019 18:23
(name . Bruno Haible)(address . bruno@clisp.org)(address . 35551@debbugs.gnu.org)
87bm0e5j43.fsf@nckx
Bruno,

Bruno Haible wrote:
Toggle quote (7 lines)
>> (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
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQT12iAyS4c9C3o4dnINsP+IT1VteQUCXNGw/AAKCRANsP+IT1Vt
eSBuAQCzvgXAB9n3447xvVSdezgSe9WJDxGwNvQEz/Tmr7x4YQD+IHCtsYZ8geKg
2jFPX7vps3DXObvj7vFuSwGAAWxUSQI=
=RKZG
-----END PGP SIGNATURE-----

B
B
Bruno Haible wrote on 7 May 2019 19:26
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)(address . 35551@debbugs.gnu.org)
2611636.VX1SFXYJk3@omega
Tobias Geerinckx-Rice wrote:
Toggle quote (13 lines)
> > 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
R
R
Ricardo Wurmus wrote on 9 May 2019 23:21
(name . Ludovic Courtès)(address . ludo@gnu.org)
87pnors4r3.fsf@elephly.net
Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (11 lines)
> 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
Closed
B
B
Bruno Haible wrote on 9 May 2019 23:57
(name . Ricardo Wurmus)(address . rekado@elephly.net)
2986777.FnrGXkQkEc@omega
Hello Ricardo,

Toggle quote (6 lines)
> > 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

Being a newbie regarding guix, I found it more comfortable to search
than through some guix command.

Bruno
Closed
R
R
Ricardo Wurmus wrote on 10 May 2019 08:18
(name . Bruno Haible)(address . bruno@clisp.org)
87mujusuho.fsf@elephly.net
Hi Bruno,

Toggle quote (9 lines)
>> > 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
Closed
L
L
Ludovic Courtès wrote on 10 May 2019 10:07
(name . Bruno Haible)(address . bruno@clisp.org)
877eay4ts3.fsf@gnu.org
Hi Bruno,

Bruno Haible <bruno@clisp.org> skribis:

Toggle quote (9 lines)
>> > 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.

Toggle quote (4 lines)
> 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’.
Closed
B
B
Bruno Haible wrote on 10 May 2019 11:38
Re: guix search
(name . Ludovic Courtès)(address . ludo@gnu.org)
3642152.sbCaK8LMaK@omega
Hi Ludo,

Toggle quote (8 lines)
> 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
Closed
L
L
Ludovic Courtès wrote on 10 May 2019 12:17
(name . Bruno Haible)(address . bruno@clisp.org)
87sgtm1umd.fsf@gnu.org
Hi Bruno,

Bruno Haible <bruno@clisp.org> skribis:

Toggle quote (15 lines)
>> 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.

Toggle quote (11 lines)
> 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.

Toggle quote (8 lines)
> 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.

Toggle quote (8 lines)
> 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’.
Closed
B
B
Bruno Haible wrote on 10 May 2019 12:18
(name . Ludovic Courtès)(address . ludo@gnu.org)
1979679.3VHG7dZlEs@omega
I wrote:
Toggle quote (3 lines)
> 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
Closed
B
B
Bruno Haible wrote on 10 May 2019 12:22
(name . Ludovic Courtès)(address . ludo@gnu.org)
1649566.Jk3XjpCMXS@omega
Toggle quote (3 lines)
> 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
Closed
B
B
Bruno Haible wrote on 10 May 2019 16:21
(name . Ludovic Courtès)(address . ludo@gnu.org)
6987474.668M4leDEz@omega
Hi Ludo,

Toggle quote (2 lines)
> we don’t know beforehand what commands a package provides.

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

Toggle quote (2 lines)
> 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
Closed
L
L
Ludovic Courtès wrote on 10 May 2019 17:17
(name . Bruno Haible)(address . bruno@clisp.org)
87k1eyz6d2.fsf@gnu.org
Bruno Haible <bruno@clisp.org> skribis:

Toggle quote (6 lines)
>> 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:


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

Ludo’.
Closed
Z
Z
znavko wrote on 10 May 2019 17:43
Re: bug#35551: guix search
(address . 35551-done@debbugs.gnu.org)
d4289a810fa965afe292a5a7a60cf68c@disroot.org
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:

Toggle quote (7 lines)
>> 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
Closed
L
L
Ludovic Courtès wrote on 10 May 2019 23:15
Re: guix search
(name . Bruno Haible)(address . bruno@clisp.org)
8736lmypsm.fsf@gnu.org
Bruno Haible <bruno@clisp.org> skribis:

Toggle quote (6 lines)
>> 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’.
Closed
B
B
Bruno Haible wrote on 10 May 2019 23:22
Re: bug#35551: guix search
(address . znavko@disroot.org)
6894874.HcgqNShRvd@omega
znavko@disroot.org wrote:
Toggle quote (7 lines)
> $ 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
Closed
M
M
Mark H Weaver wrote on 11 May 2019 00:04
(name . Ludovic Courtès)(address . ludo@gnu.org)
87sgtm0xuw.fsf@netris.org
Hi,

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

Toggle quote (11 lines)
> 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
Closed
B
B
Bruno Haible wrote on 11 May 2019 00:38
(name . Mark H Weaver)(address . mhw@netris.org)
1724203.DhVHnQV9by@omega
Mark H Weaver wrote:
Toggle quote (6 lines)
> 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
Closed
T
T
Tobias Geerinckx-Rice wrote on 11 May 2019 01:41
(name . Bruno Haible)(address . bruno@clisp.org)
877eaxzxlg.fsf@nckx
Bruno Haible wrote:
Toggle quote (21 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQT12iAyS4c9C3o4dnINsP+IT1VteQUCXNYMKwAKCRANsP+IT1Vt
eTMAAQCmVb6wR9S41HLvmAdQjFPefjmEotyPA8C/P98mkOYj3AEArqpzVHpA/ne1
iT0kg1jAAcOL754Ju8J0cfgPUuYsOQ0=
=LSLN
-----END PGP SIGNATURE-----

Closed
M
M
Mark H Weaver wrote on 11 May 2019 20:18
(name . Bruno Haible)(address . bruno@clisp.org)(address . 35551-done@debbugs.gnu.org)
874l6026sx.fsf@netris.org
Hi Bruno,

Bruno Haible <bruno@clisp.org> writes:

Toggle quote (14 lines)
> 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
Closed
M
M
Mark H Weaver wrote on 11 May 2019 20:38
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)
87zhnszvia.fsf@netris.org
Hi Tobias,

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

Toggle quote (23 lines)
> 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.

Toggle quote (2 lines)
> 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
Closed
L
L
Ludovic Courtès wrote on 13 May 2019 09:57
(name . Mark H Weaver)(address . mhw@netris.org)
877eauvla9.fsf@gnu.org
Hi Mark,

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

Toggle quote (28 lines)
> 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’.
Closed
Z
Z
znavko wrote on 13 May 2019 17:39
cb73ed41279956561da0afb1375b5b54@disroot.org
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:

Toggle quote (46 lines)
> 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’.
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 35551@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 35551
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch