[bug#28045] [PATCH] gnu: Add openfoam

[ludo@gnu.org (Ludovic Courtès)]

Hi Paul,

Paul Garlick <pgarlick@tourbillion-technology.com> 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.  Firstly, if it the layout remains upstream's
> responsibility it makes the Guix maintenance task simpler.  Secondly,
> OpenFOAM users will immediately recognise the standard structure.

OK, makes sense.

>> Or perhaps there’s a middle ground we could find?  
>
> Possibly but we would need to think of a way to avoid version clashes.
>  
>
> One objective in packaging OpenFOAM for Guix is to allow users to have
> multiple versions of OpenFOAM installed at once.  This is a common

[...]

> Could we achieve this versatility using a Guix-like layout?  A possible
> 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/…

Does it address the use case you have in mind?

That’s how we deal with conflicting package version requirements in the
vast majority of cases.  There are also some packages for which
upstream’s build system explicitly supports “parallel installation” of
different versions (Guile, Python, GLib, etc.).

Thanks,
Ludo’.