From mboxrd@z Thu Jan 1 00:00:00 1970 From: mikadoZero Subject: Improve package search Date: Thu, 14 Mar 2019 14:31:36 -0400 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([209.51.188.92]:33903) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h4WTA-00026z-EG for guix-devel@gnu.org; Thu, 14 Mar 2019 15:56:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h4WDX-0003ZM-QF for guix-devel@gnu.org; Thu, 14 Mar 2019 15:40:40 -0400 Received: from forward106p.mail.yandex.net ([2a02:6b8:0:1472:2741:0:8b7:109]:40988) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h4WDX-0003XO-Bu for guix-devel@gnu.org; Thu, 14 Mar 2019 15:40:39 -0400 Received: from mxback4j.mail.yandex.net (mxback4j.mail.yandex.net [IPv6:2a02:6b8:0:1619::10d]) by forward106p.mail.yandex.net (Yandex) with ESMTP id 9F18C1C80E22 for ; Thu, 14 Mar 2019 21:31:56 +0300 (MSK) List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Guix-devel # Motivation >From Ludovic Court=C3=A8s response to bug#34828: > "I would recommend against turning descriptions into lists of commands > just for the sake of package search (we should instead have another > mechanism to determine which package provides a given command) ..." `guix package -s` often returns no useful results for a program that is part of a larger multi program package with a different name. This is heightened by the very reasonable desire to prevent descriptions form turning into lists of commands. # Examples Here two examples of programs that do not have useful package search results: `as` in `gcc-toolchain` `recsel` in `recutils` There are other programs that also have this issue. # Proposed idea * Add a "programs" field to package definitions that list the programs that are included in a package.=20 * Include this field in search results. * Have this field factor into the search result relevance scores. # Implementation I am not familiar with how package search works and do not know how much work this would be to implement. A requirement for a "programs" field could be included in package linting. I am not familiar with the inner workings of linting and do not know how much work this would be to implement. # Roll out * New packages could be given the "programs" field when they are created. =20=20 * Existing packages that are being updated could be given the "programs" field. * Existing packages with relevant irc questions or bug reports could be given the "programs" field. * Existing packages without relevant irc questions or bug reports that are not being updated could remain unchanged. This could save significant effort as many programs may never require the "programs" field to be added. # Advantage Allow users to better find what package includes the program they want to install. # Disadvantage More effort required to package multi program packages. I know that the coreutils package includes a very large number of programs. I do not know if there are many other packages that are also as large. # Feedback This is an initial idea that would benefit from the input of others. Given the uncertainties I mention in the Implementation and Disadvantages sections this may not be a good solution for the Motivation section.