Kei Kebreau writes: > Alex Vong writes: > >> Kei Kebreau writes: >> >>> Alex Vong writes: >>> >>>> Hello Kei, >>>> >>>> Kei Kebreau writes: >>>> >>>> [...] >>>>> >>>>> Here are two tentative patches that make the changes we've discussed. >>>>> Also, should we make a deprecated-package definition for qtoctave? >>>> >>>> I think some additional changes related to "(assoc-ref inputs ..." >>>> needed to be made. Otherwise, looks good to me! Here is a patch I made >>>> earlier but it was not tested, feel free to cherry-pick what is needed: >>>> >>>> From 2b04caa66c17da257dfb4f4ccb94e8d629b95e53 Mon Sep 17 00:00:00 2001 >>>> From: Alex Vong >>>> Date: Mon, 3 Dec 2018 03:39:40 +0800 >>>> Subject: [PATCH] gnu: Rename "octave" to "octave-cli" and "qtoctave" to >>>> "octave". >>>> >>>> * gnu/packages/maths.scm (octave): Rename to octave-cli. >>>> [name]: Change to "octave-cli". >>>> (qtoctave): Rename to octave. >>>> [name]: Change to "octave". >>>> [inherit]: Inherit from octave-cli. >>>> [source]: Likewise. >>>> [inputs]: Likewise. >>>> [native-inputs]: Likewise. >>>> [arguments]: Likewise. >>>> (flann): Update accordingly. >>>> * gnu/packages/engineering.scm (qucs): Likewise. >>>> (qucs-s): Likewise. >>>> * gnu/packages/machine-learning.scm (shogun): Likewise. >>> >>> ... >>> >>>> - ("octave" ,octave) >>>> + ("octave-cli" ,octave-cli) >>> >>> I see the main difference is that you've replace the package's >>> associated string to "octave-cli" as well as the name, whereas I've only >>> replaced the package name. Should I replace the associated package >>> string, too? >> >> According to the manual "6.7.2 Package Naming", the associated string is >> used for package management commands such as 'guix package' and 'guix >> build'. Therefore, I think we should change them as well, so that the >> users can install the packages using the command >> "guix package -i octave-cli" and "guix package -i octave" >> respectively. What do you think? > > Maybe this is true when manipulating the package definition, but that > doesn't seem to be the case in general. When I run > "./pre-inst-env guix package --show=shogun", for example, > "octave-cli@4.4.1" is listed as a dependency, even though "octave" is > the associated name in shogun's input list. > > To be clear, I've changed the string for octave's and octave-cli's > package name in their respective package definitions, but I haven't > changed the string in the input lists of octave-cli's dependent > packages. > > I'm inclined to follow convention when it comes to this, and other > packages in input lists seem to omit extensions to the base name of the > package in their assoc-lists. For example, ("gettext", gettext-minimal) > and ("python", python-minimal-wrapper) are common inputs for packages. I think you are right! This was a misunderstanding on my part. I thought the association string in the input lists must be the same as the package name, but appraently this is not the case. Take gettext-minimal as an example, its variable name is 'gettext-minimal', its package name is "gettext-minimal", but its input name is "gettext".