Drew On 2020-04-01 22:28, Mark Olesen wrote:
Hi Drew, Looking at the petsc package does indeed provide some interesting pointers. I also noticed that you wrote up the README.Debian for it. With OpenFOAM we will later have a similar situation. In addition to the different versions, we also have different flavours such as single/double/mixed and int32/int64 combinations. Unlike PETSc, we do not yet have an intelligent means of managing the configurations. We either have a central config file to edit, or a single "prefs" file for similar things. Cheers, /mark On 2020-04-01 04:50, Drew Parsons wrote:Hi Mark, thanks for starting on debian packaging.Quoting a comment made recently on irc #debian-devel, "parallel installable -dev packages is a bad idea in most cases". To which I replied, "in most cases".As you say, it's not uncommon in scientific computing to want parallel installations of multiple versions. For instance in a long-term research project, you might not want to deal with the code changes (not to mention output changes) that accompany a new version of the tool you're using.I recommend looking at the PETSc packaging. In the case of PETSc, upstream has made it very reason to install multiple versions. A user selects the required version with the environment variable PETSC_DIR.In Debian we've handled the PETSc packaging by installing the various versions into /usr/lib/petscdir, with symlinks where needed to libpetsc*.so.* in /usr/lib/${DEB_HOST_MULTIARCH}. For instance if you haven't updated your code for the API changes that came with PETSc 3.8, you can keep using 3.7 with PETSC_DIR=/usr/lib/petscdir/3.7.Debian also has an alternatives mechanism for handling preferred versions ('update-alternatives --config petsc'). Since PETSc has both real and complex builds I've set up web of various alternatives (arguably overkill) - petsc: sets /usr/lib/petsc, /usr/lib/${DEB_HOST_MULTIARCH}/libpetsc.so, the preferred build and version (this gets used if PETSC_DIR is not otherwise specified) - libpetsc.so.3.12: sets /usr/lib/petscdir/3.12, /usr/lib/${DEB_HOST_MULTIARCH}/libpetsc.so.3.12, the preferred build (real or complex) for PETSc 3.12 - libpetsc_real.so: sets /usr/lib/petscdir/petsc-real, /usr/lib/${DEB_HOST_MULTIARCH}/libpetsc_real.so, the preferred version for a real build - libpetsc_complex.so: sets /usr/lib/petscdir/petsc-complex, /usr/lib/${DEB_HOST_MULTIARCH}/libpetsc_complex.so, the preferred version for a complex number buildProbably you don't need that much complexity in OpenFOAM (assuming it only has a real number build), but you could using some kind of alternatives to manage your versions.Also (a bit simpler to set up than the alternatives), you can create dummy packages, e.g. libopenfoam-dev could be a dummy package that depends on the latest versioned package libopenfoam1912-dev (petsc-dev, libpetsc-real-dev, libpetsc-complex-dev serve this role for PETSc)Drew On 2020-04-01 04:11, Mark Olesen wrote:I've been in discussion with Kurt about the openfoam package and have been looking at adjusting (improving) its structure. Being very new to debian (and especially debian packaging), there are a few things that I'd like to get some more ideas about - thus the posting here. With OpenFOAM it is fairly common for users to have multiple versions installed at any one time. For example, to migrate coding for API changes between versions, or to validate the results of models using different versions before making a complete switch, or even if an element is partly broken in a newer version but works in an older version.In the RPM world, I've handled this by an admittedly somwehat ugly approach.1) Version-specific packages such as openfoam1906, openfoam1912 etc with a "minor" version according to the patch-level (eg,https://build.opensuse.org/package/view_file/science/openfoam1912/openfoam1912.spec) 2) An openfoam meta-package to specify the latest production versionby requiring the version-specific package (eg,https://build.opensuse.org/package/view_file/science/openfoam/openfoam.spec) To allow simultaneous installation of multiple versions, I'm installing into /opt/openfoam1912, /opt/openfoam1906 etc. This is okayfor a third-party package, but not for a debian-package. What would be the correct place for these? IMO, using alternatives is not viable. There are simply too many exes and libs, names may change, etc.Had thought about dropping everything into a multi-arch directory, butnot sure how that should be properly realised, and where the sources would then be located. Looking for ideas and discussion. Cheers, /mark