[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: proper structuring of a package

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.



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 build

Probably 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)


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

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,

2) An openfoam meta-package to specify the latest production version
by requiring the version-specific package (eg,

To allow simultaneous installation of multiple versions, I'm
installing into /opt/openfoam1912, /opt/openfoam1906 etc. This is okay
for 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, but
not sure how that should be properly realised, and where the sources
would then be located.

Looking for ideas and discussion.


Principal Engineer, ESI-OpenCFD
Engineering System International GmbH | Einsteinring 24 | 85609 Munich
Mob. +49 171 9710 149
www.openfoam.com | www.esi-group.com | mark.olesen@esi-group.com

Reply to: