From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56586) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dqEaB-0005kw-Th for guix-patches@gnu.org; Fri, 08 Sep 2017 04:24:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dqEa4-0008Qf-6o for guix-patches@gnu.org; Fri, 08 Sep 2017 04:24:11 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:46543) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dqEa4-0008QP-2Z for guix-patches@gnu.org; Fri, 08 Sep 2017 04:24:04 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dqEa2-0008A1-60 for guix-patches@gnu.org; Fri, 08 Sep 2017 04:24:02 -0400 Subject: [bug#28045] [PATCH] gnu: Add openfoam Resent-Message-ID: From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) References: <1504105724.3260.10.camel@tourbillion-technology.com> <20170906212801.4311-1-pgarlick@tourbillion-technology.com> <87r2viwwkp.fsf@gnu.org> <1504818378.3116.38.camel@tourbillion-technology.com> Date: Fri, 08 Sep 2017 10:23:05 +0200 In-Reply-To: <1504818378.3116.38.camel@tourbillion-technology.com> (Paul Garlick's message of "Thu, 07 Sep 2017 22:06:18 +0100") Message-ID: <87y3ppk39y.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Paul Garlick Cc: 28045@debbugs.gnu.org Hi Paul, Paul Garlick skribis: >> Would it be possible to follow a layout closer to what we usually do: > > There are some advantages of keeping the standard OpenFOAM layout, > different though it is. =C2=A0Firstly, if it the layout remains upstream's > responsibility it makes the Guix maintenance task simpler. =C2=A0Secondly, > OpenFOAM users will immediately recognise the standard structure. OK, makes sense. >> Or perhaps there=E2=80=99s a middle ground we could find? =C2=A0 > > Possibly but we would need to think of a way to avoid version clashes. > =C2=A0 > > One objective in packaging OpenFOAM for Guix is to allow users to have > multiple versions of OpenFOAM installed at once. =C2=A0This is a common [...] > Could we achieve this versatility using a Guix-like layout? =C2=A0A possi= ble > problem might be executable files in version B clashing with executable > files of the same name in version A, if they both share the > $GUIX_PROFILE/bin directory. If we provide a bin/ directory, then trying to install two different versions in the same profile will lead to a clash (and anyway, Guix raises an error when trying to install two different packages that have the same name in the same profile). However, Guix supports multiple profiles, so one can always do: guix package -i openfoam@1.2 -p old-openfoam guix package -i openfoam@2.0 -p new-openfoam ./old-openfoam/bin/openfoam ./new-openfoam/bin/openfoam Or, alternatively: $ guix environment --ad-hoc openfoam@3.4 [env]$ $GUIX_PROFILE/bin/=E2=80=A6 Does it address the use case you have in mind? That=E2=80=99s how we deal with conflicting package version requirements in= the vast majority of cases. There are also some packages for which upstream=E2=80=99s build system explicitly supports =E2=80=9Cparallel insta= llation=E2=80=9D of different versions (Guile, Python, GLib, etc.). Thanks, Ludo=E2=80=99.