From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kei Kebreau Subject: Re: Octave & QtOctave Date: Sat, 08 Dec 2018 13:23:43 -0500 Message-ID: <87mupfx4gg.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> <87in06mzjz.fsf@posteo.net> <87zhtilf2k.fsf@gmail.com> <87tvjpwd09.fsf@posteo.net> 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]:43025) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gVhGf-0000jR-Ki for guix-devel@gnu.org; Sat, 08 Dec 2018 13:23:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gVhGc-0001zC-D2 for guix-devel@gnu.org; Sat, 08 Dec 2018 13:23:57 -0500 Received: from mout02.posteo.de ([185.67.36.66]:33453) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gVhGb-0001wF-TB for guix-devel@gnu.org; Sat, 08 Dec 2018 13:23:54 -0500 Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id B49802400E6 for ; Sat, 8 Dec 2018 19:23:45 +0100 (CET) In-Reply-To: <87tvjpwd09.fsf@posteo.net> (Kei Kebreau's message of "Fri, 07 Dec 2018 10:52:06 -0500") 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 Kei Kebreau writes: > Alex Vong writes: > >> 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". > > Precisely! Unless anyone else has concerns that should be brought to > light, I'll be committing this within the next 2 days. > > Thank you to all involved so far. I've pushed this to master. Thanks again! --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEg7ZwOtzKO2lLzi2m5qXuPBlGeg0FAlwMDC8ACgkQ5qXuPBlG eg1hsxAAvpMSfWr2sJfmCcFDxS2t9gMrBBOFueXqW6tC/7A4FoFYinXU/1OPFZPe YG5XUpx/Wk/9f634VWShWhLXP0p7mCDSfb4kdq3IjHQXgkLjN/nctUkejV6sxNp0 8ef4GHRIr2fp1HqrFYqbtzjianfw/Y8s3JhlDWPBxu9ZxCylMHC+6P7plS57+RBk 9PNiG05dLykr6AC1n45Vp0iQNrgYDoQxp76LJYL0ncoviC/mi7TwCGCMvZgVXO0G TDgNjGgs/sIz02Us23DQzajxePOj12kfQSbpFwKOYDTNkPOoxHnd1H65WzppYbDg G0E7kV1G6ji7SfnwW0ZoLyLG5yQcjvefA84yQwj6bkAwy4Eyzq6Yzic/OCglwoz7 xkeRFHGtFYuyLoizmOVNLxLWqJC8pvQguMIetrEApZoISpDCGGIjgIgXcQzHSL63 9LxQbnQ5XNfNL9sCr0BuLxgy/Mdg6eFO02ukUzAbE5Yls9eGn3xA7taCstaoaM1K oXSOe+nVvTnREjvESCqX2x7WXksCzS1SJdeDUBDkdi0KZS0tdNJQnn1G2d69J+9c 6LUwzjylgNxEwjsDXJXfwsHyH9bjx3Pl5JF+MCzWpuZOUFUdYU71pIeg34FMfIXO R4dZ/DGrfQbvA4c0Ks3NqIYowdTc3hNWmhXx4DMo12FCARkq1j4= =a79p -----END PGP SIGNATURE----- --=-=-=--