From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kei Kebreau Subject: Re: Octave & QtOctave Date: Thu, 06 Dec 2018 10:42:56 -0500 Message-ID: <87in06mzjz.fsf@posteo.net> References: <875zwnqomz.fsf@posteo.net> <87a7lyzkk2.fsf@gmail.com> <20181124221022.ankjuz4mdpkoohkn@abyayala> <87k1l1w3n0.fsf@gnu.org> <87in0ijtku.fsf@posteo.net> <87va4h5vhr.fsf@gnu.org> <87a7lnk9sb.fsf@posteo.net> <871s6xz894.fsf@gmail.com> <87woopovyk.fsf@posteo.net> <878t13mdcj.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54505) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gUvo8-0003my-7d for guix-devel@gnu.org; Thu, 06 Dec 2018 10:43:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gUvo3-0002IX-D9 for guix-devel@gnu.org; Thu, 06 Dec 2018 10:43:19 -0500 Received: from mout02.posteo.de ([185.67.36.66]:60707) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gUvo0-0002EQ-Kj for guix-devel@gnu.org; Thu, 06 Dec 2018 10:43:13 -0500 Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 26F7F2400FC for ; Thu, 6 Dec 2018 16:43:06 +0100 (CET) In-Reply-To: <878t13mdcj.fsf@gmail.com> (Alex Vong's message of "Thu, 06 Dec 2018 13:30:20 +0800") 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: Alex Vong Cc: guix-devel --=-=-= Content-Type: text/plain 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. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEg7ZwOtzKO2lLzi2m5qXuPBlGeg0FAlwJQ4AACgkQ5qXuPBlG eg3onhAAljYT/zLtHhe3DIgHc707pRgZES5sQPvJbiK+VOFKRGFDqhRyne17xBbM mS9ZaOD3/lwe7HqLRPhLVZCNjjs1856wMhzAAkLNnZtCTjo5dknGkizPeiZMTQza PechWKPr13LNhmwVx7iGghTJk8K636TM/mk2ish3ws9JKYHpM27zCJCeqGL8nWWn ypXjUtCcEjXHC+3FWEEPe4X+XNvCSq1VYueRDI47PgXcdOfI+QdihGQfp+HFYeIs r1LLpuJY3V4DiNgFHIqjlCD6fm9hPfAqK25N10W9JhxJaudDmOPckzo+wN8X06Yl wG+CwV5GfFA4I/ptdDxGyV5IFb0Bkir2dFzmIqOp55qJHvzJszhN6kbdairRLB4c +s3o7u/Dkk80EGUQukDss+OiBJ1ekokvRSVLkqQaol74cDBgAcNxDCB0jYVgXa2v OButt14VmHKmmuMjOxj/1ytPqqnFcgysgMTdfwmfMwZAXzI6wMHP8Zr7gPPv74dD QoTOR3NHSHv8+Q/UZ1WrmEhZWBV4uXe09b1Eg7hhDx9JrJZO4LxovQrUx++PbRpU lV9koum3d22neCKrdVRnorLMS2CgLQGqGLY3Udu89Muvc1yVz4MXASl37kRm8ISF 0Me6tS5T5w2HXqUoisFohinwcm07cgteuSKqpgi/7dcx/eCoklk= =+SpJ -----END PGP SIGNATURE----- --=-=-=--