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

Re: Packaging Open Porous Media (OPM) software suite



Hi Markus,

Welcome on board! I have added you to the salsa group of the
Debian Science Team. Feel free to push your projects there.

I did not have a deep look into the packaging, but have some notes:

- Try to use the newer compat-version. 11 is a little bit outdated.
- Please add autopkgtests for packages.
- Try to add Gitlab-CI for every package. It definitely improves the package quality
  and makes the package maintenance easier.
- Please consider reducing the number of source packages. Uploading/sponsoring
  7 source packages, especially if some of them should go through NEW queue. It is
  pain.

> - In the future we imight want to  be able to install several versions....

I would recommend not to do it. At least in the official version of the Debian package.
That just means that every new upload should have another binary name, NEW queue,
sponsoring from DD etc. It can only have sense for very big and very popular packages
like boost for example. But for small scientific packages it is just overhead.

> Does the top-level directory in the tarballs need to have a special....

No. If you do "dpkg-source -x AAA.dsc" the top level directory will be overwritten.

Just a general note. Make the simple things not too complicated. Otherwise
the package will not work and is very difficult in maintenance.

Best regards

Anton


Am Mi., 28. Apr. 2021 um 15:40 Uhr schrieb Markus Blatt <markus@dr-blatt.de>:
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: