Packaging Open Porous Media (OPM) software suite
Hi,
I have recently posted an ITP (bug )for this software
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987381
<begin citation bugreport>
* Package name    : opm-common, opm-material, opm-grid, opm-models, opm-
simulators, opm-upscaling
 Version         : 2021.04
 Upstream Author : OPM <opm@opm-project.org>
* URL             : https://www.opm-project.org/
* License         : GPL2+/GPL3+
 Programming Lang: C++, Python
 Description     : Open Porous Media (OPM) software suite
.
The Open Porous Media (OPM) software suite provides libraries and  
tools for modeling and simulation of porous media processes, especially 
for simulating CO2 sequestration and improved and enhanced oil 
recovery.
<end citation bugreport>
I am part of the OPM development team. We are prepared to maintain the 
packages, but as nobody of us is a Debian developer, we would of course 
need help for uploading. We have not done so, but intend to ask Ansgar 
Burchardt whether he has time for this.
I have an account on salsa and the current version of the packaging 
effort can be found there.  https://salsa.debian.org/blattms/opm-common 
https://salsa.debian.org/blattms/opm-material 
https://salsa.debian.org/blattms/opm-models 
https://salsa.debian.org/blattms/opm-grid 
https://salsa.debian.org/blattms/opm-simulators 
https://salsa.debian.org/blattms/opm-upscaling To us as recreational 
packagers this looks good now, but chances are that we have missed 
stuff.
I also requested being added to the Debian Science team on Salsa, but 
that does not seem to have happened yet (or I missed it). Once that 
happens I will gladly push to https://salsa.debian.org/science-team.
Some notes on the packaging:
- Packaging is based on the branch point (git commit) for the upcoming 
 2021.04 release. Once that is released we will add the new version.
- We use git-buildpackage with the default layout and pristine-tar 
 (there is a debian/dbp.conf file that activate pristine-tar, and tells
 it which files to strip from upstream)
- We have stripped some sources for the Debian packaging (jenkins, 
 travis, embedded source code, upstream packaging for Redhat, Debian, 
 OpenSuse) to satisfy the Debian Policy and prevent unnecessary changes 
 from appearing in the Repositories of the Debian packaging. Note that 
 these are also stripped from the tarballs and listed in 
 debian/copyright (Excluded-Files) and debian/gbp.conf for ease of 
 maintenance.
- Apart from opm-material and opm-models, which are header-only 
 libraries and missing lib<project>.deb because of this, most 
 repositories create Packages lib<project>-dev.deb, lib<project>.deb,
 lib<project>-doc.deb and (for opm-common, opm-grid, opm-simulators) 
 lib<project>-bin.deb. There are also packages with python bindings: 
 python3-opm-common.deb, python3-opm-simulators.deb
- For the library packages the SONAME will change with each release, as 
 the ABI is quite unstable. The version is not part of the library 
 package name, which lintian would warn about. But we are overwriting 
 the warning currently.
- opm-upscaling is missing manpages for the binaries. This will be fixed 
 upstream and backported soon.
Some questions:
- In the future we imight want to  be able to install several versions 
 of libopm-simulators-bin.deb concurrently (which would need to depend 
 on different versions of the library packages lib<project>.deb, and 
 probably install binaries into different versioned directories and use 
 update-alternatives. Is there a proposed policy/approach to do this? I 
 would assume that this needs to be prepared now by putting some kind 
 of versioning into the Debian packages for the libraries (e.g. like 
 Petsc).
- Does the top-level directory in the tarballs need to have a special 
 name (like opm-common-2021.04 for version 2021.04 of opm-common)?
 The reason for asking is that upstream tags final versions as 
 release/<version>/final, which will make uuscan us funny looking
 opm-common-release-2021.04-final. If it does upstream needs to use the 
 more common tagging scheme v<version>, or we need to create the 
 tarballs ourselves and use gbp import-orig <tarball>.
Thanks a lot for your kind help.
Cheers,
Markus
--
Dr. Markus Blatt - HPC-Simulation-Software & Services http://www.dr-blatt.de
Pedettistr. 38, 85072 Eichstätt, Germany,  USt-Id: DE279960836
Tel.: +49 (0) 160 97590858
Reply to: