Initial debianization

[fortysixandtwo]

Closes #4163

Description of changes:

• Introduce debian packaging
• The test suite currently does not work (causing the package build to fail)

Regarding the test suite failure: I tried skipping the tests by using dh_override_autotest in d/rules
but I guess I'm not doing it right :?

I might investigate further why the package won't build, but no promises there.

[fortysixandtwo]

You should be able to build with dpkg-buildpackage -us -uc or gbp buildpackage.

Also I wasn't entirely sure about the copyrights, so please give this a look (but this might only be a problem when you're aiming for inclusion in Debian/Ubuntu).

git-buildpackage is very nice as it will allow you to create changelog entries in debian/changelog by invoking something like gbp dch --auto which will use the commit messages to generate entries.

[fortysixandtwo]

Correctly overriding the tests now (haven't checked WHY the tests fail on my system though) so that the package gets built correctly. Also corrected Build-Depends and Depends. Checked that it builds in a clean chroot

[RudolfWeeber]

Thank you for this PR! We'll probably need a while to move forward, here, since none of us is familiar with the packaging tools.
We are also discussing, how to include this into our CI/CD infrastructure.

[fortysixandtwo]

In case you have specific questions, just shoot :)

Regarding CI: Basically you would need to run two commands (works in Debian Bullseye, but I guess it should also work on the Ubuntu 20.04 docker image you are currently using).

• apt build-dep . to install the dependencies
• dpkg-buildpackage -us -uc -us is used for "unsigned source" and -uc for unsigned .changes file (you can of course also sign with your gpg key in which case you could drop those flags)

[RudolfWeeber]

• Updated build-dependencies and install dependencies
• The package build is now run in a clean Ubuntu container to test build deps, then, the package is test-installed in a new clean Ubuntu container to test the truthfulnes of the dependencies.

Next step is to make a policy decision on what packages we will provide:

• For releases?
• Weekly snapshtos for dev branch?
• Which Ubuntu and/or Debian versions?
• As PPA or just as package binary?

Should probably be taken to an ES meeting.

[RudolfWeeber]

Can the debain folder be placed somewhere else, e.g. under maintainer?

[fortysixandtwo]

@RudolfWeeber: Not sure, but I think the debian/ folder needs to be in the root.

Alternatively the packaging could live in a different repository/branch (or I could maintain it in the Debian Science team (which would automatically trickle down to the forks Ubuntu etc)

[fortysixandtwo]

If you'd be interested I can try packaging it inside Debian. I'm not sure how long it takes until it lands in ubuntu.

If such a package were provided I believe it would only really be useful to newcomers since everyone else
will probably compile from sources instead of using a prebuilt binary package. I bring this up in case you would
prefer the build configuration to explicitly enable or disable specific features (f.e. I would lean to enabling
everything that doesnt rely on CUDA and/or MPI)

I understand that you might not want to carry the debian/ folder which is why I brought up that the packaging could live
on a different branch or even in a downstream fork (which is what I would do if/when I'm going to package it for Debian).

Feel free to give me a shout once you decide how to proceed.

[RudolfWeeber]

Thank you for the offer

We were discussing inclusion in Debian/Ubuntu. While that would make it easy for new users, the rather long release cycle of Debian stable is an issue. We typically stop running CI on older releases (and also stop supporting the CI infrastructure for it in some cases). We therefore recommend to users to always use the current release version of Espresso.
That's why we are leaning towards hosting a PPA.

Feature-wise, the default config is fine. It includes nearly everything.

[fortysixandtwo]

We were discussing inclusion in Debian/Ubuntu. While that would make it easy for new users, the rather long release cycle of Debian stable is an issue.

I can understand that you probably don't want to see bug reports for ancient versions which you do not support any more.

Two things: If someone wants to get all the latest bells and whistles there is always the testing or sid/unstable suite (as a matter of fact Ubuntu bases itself on testing). And this is in fact where all packages get uploaded to until they are frozen when a new stable suite is prepared.

It would also (generally) be possible to backport newer versions into stable.
Unless required dependencies have been bumped a lot this should be rather straight forward (this maintenance burden falls on you if you go the PPA route).

With that said: If you strongly prefer not have it packaged in Debian/Ubuntu then I'm perfectly fine with that.
Personally I just don't like external repositories very much and don't think it's a good idea to avoid distributions (this is what they are actually good at) and make users setup a PPA.

I can offer to maintain the packaging of espresso in Debian and then all the derivatives (f.e. the Ubuntus of the world) can just apt install espressomd.

Please tell me if this is acceptable.