Re: Packaging Open Porous Media (OPM) software suite
Hi Anton,
thanks a lot for the help and kind suggestions. I continued to work on
the opm-common package with your suggestions in mind. Current status is:
- CI and autopkgtest added.
- "build i386" as the upstream tests fail on this platform.
One of the reasons is probably the Y2k38 problem on this architecture.
That make the OPM quite unusable if one wants to simulate longer than
17 years (for CO2 storage shorter is not really interesting. The
problem here is that fixing this might be a lot of work for very
little gain.
Is support for i386 really mandatory or can I restrict the package to
64bit platforms only?
Can I restrict Architecture in debian/control to 64bit only?
-reprotest times out. Not sure whether I can fix this and how to
proceed.
See https://salsa.debian.org/science-team/opm-common/-/pipelines/257626
On Wed, Apr 28, 2021 at 09:09:51PM +0200, Anton Gladky wrote:
- Try to use the newer compat-version. 11 is a little bit outdated.
Done.
- Please add autopkgtests for packages.
Very good suggestion that started revealing bugs at once. I have added
that and fixed the bugs in opm-common.
What I am wondering is, how this will work with our dependencies on new
packages. If we build opm-grid we would need the packages build from the
source package opm-common. Is there documentation on how to do this with
the Debian CI. (I have this working with cowbuilder on my machine, but
that needs manually copying the deb files.
- Try to add Gitlab-CI for every package. It definitely improves the
package quality
and makes the package maintenance easier.
Done for opm-common but some tests are failing.
- 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.
Each of the source packages has its own repository upstream. This was
decided to allow easier reuse and using only parts of OPM. For example
opm-grid, opm-material, and opm-models as DUNE modules might be of
interest to other projects, but they might not want to pull in the rest
of OPM.
I always assumed that Debian source package correspond to official
upstream tarballs/repositories. If that is not the case one could
create an artificial Super-repository that pulls in the other
repositories as CMake subprojects. Then one could use that repo as the
upstream repository, but would risk some detachment of the releases due
to more maintenance overhead.
Was this what you are suggesting? Please clarify.
- 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.
I was not intending to have serval official versions. Just the ability
to have e.g. libopm-*-2020.04, libopm-simulators-2020.04-bin in official
Debian and maybe ship libopm-*-2021.04, libopm-simulators-2021.04-bin in
a private repo to make users compare two versions of the simulator.
This means of course that the names need to be adjusted in
debian/control with each release. Is that too much complication?
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.
Perfect. Keeping this simple.
Thanks a lot for all the help.
Cheers,
Markus
Reply to: