search

openmm / openmm

OpenMM is a toolkit for molecular simulation using high performance GPU code.
1.48k stars 521 forks source link

Debian package for OpenMM 7.4.0 #2784

Open jchodera opened 4 years ago

jchodera commented 4 years ago

It just came to my attention that OpenMM 7.4.0 is made available as a debian package maintained by @merkys via https://salsa.debian.org/merkys-guest/openmm

See https://lists.debian.org/debian-devel-changes/2020/07/msg01416.html

Perhaps it would be useful to coordinate to make sure this package is up to date with the latest release?

peastman commented 4 years ago

That's already two versions out of date, so it clearly isn't being properly maintained. :( This is exactly what I was afraid of when the discussion about Debian packages first came up.

merkys commented 4 years ago

OpenMM in Debian is actually even more recent than 7.4.2. It is based on a commit after #2713 was merged (early June), as #2713 was a prerequisite to get OpenMM into Debian. The reason 7.4.0 is displayed in the version is because git describe --tags is used on the master branch to determine the version string. I have just realized that git tags after 7.4.0 are made on 7.4_branch branch, not master - my bad, I will fix the version number.

I would be more than happy to create packages for proper OpenMM releases, not git commits. However, as said, I can only package a release with #2713 in its code.

peastman commented 4 years ago

That's even worse: it means people are getting unreleased development code with known bugs that are likely to lead to incorrect behavior. And they have no idea of that.

jchodera commented 4 years ago

@merkys : It would be awesome if we could work together to make sure the debian packages match OpenMM stable and validated releases! Is there a way we can notify you and help update things when we cut new releases (following our testing and QA protocol)?

merkys commented 4 years ago

That's even worse: it means people are getting unreleased development code with known bugs that are likely to lead to incorrect behavior.

As said, I would be more than happy to use stable releases instead of development code. On the other hand, development code sometimes has advantages over stable releases, as bugs known to exist in the previous release may be already fixed in development code.

And they have no idea of that.

I do not agree with this. Debian packages based on development code always have version suffixes like +git<date> or .g<commit-hash> (as per git describe --tags). OpenMM package is not an exception.

@merkys : It would be awesome if we could work together to make sure the debian packages match OpenMM stable and validated releases! Is there a way we can notify you and help update things when we cut new releases (following our testing and QA protocol)?

I would happily do so! There is a service in Debian which informs the packagers about new releases of packaged software every day. All what is expected from the upstream developers are git tags, and OpenMM already has them.

jchodera commented 4 years ago

Awesome! Let us know if we can be of further help, @merkys.

peastman commented 4 years ago

Could you describe how this works from the user's perspective? Since this isn't a release, I assume the user has to do something more than just apt install openmm?

merkys commented 4 years ago

Could you describe how this works from the user's perspective? Since this isn't a release, I assume the user has to do something more than just apt install openmm?

From the user's perspective, all packages are installed with apt install. It's the version string which indicates whether a package corresponds to a release, or not.

peastman commented 4 years ago

What happens if someone just types apt install openmm without specifying a version? Would that currently give them a development build?

merkys commented 4 years ago

What happens if someone just types apt install openmm without specifying a version? Would that currently give them a development build?

Yes, it would.

If distributing development builds via Debian is absolutely unacceptable to you, I can withhold the created Debian packages until the next release of OpenMM. It's just that doing so would prevent its reverse dependencies (such as MacroMoleculeBuilder) from being distributed too.

peastman commented 4 years ago

Yes, please do withhold it. Generally speaking, development builds are intended only for testing and development. A user should never get a development build without being clearly aware that's what they're getting. If someone tried to use it for their production simulations, that could lead to months of wasted effort, retracted papers, etc.

Thanks!

mbanck commented 4 years ago

Not sure it would help building MacroMoleculeBuilder, but as long as there is no released version of openmm with proper shared library versioning support, you/Debian could just ship a static dev library to use. That makes tracking API/ABI changes your job, but if it for just one or two downstream packages, it is usually doable, provided openmm is not too much of a moving target.

As the current version in Debian testing/unstable is 7.4.0.491.gac5a8f71+dfsg-1, packaging 7.4.2 that way wouldn't be a problem. I haven't looked at the code or the build system in detail, though, so might be totally off with this.

merkys commented 4 years ago

Yes, please do withhold it. Generally speaking, development builds are intended only for testing and development. A user should never get a development build without being clearly aware that's what they're getting. If someone tried to use it for their production simulations, that could lead to months of wasted effort, retracted papers, etc.

Request to withhold the package posted.

Not sure it would help building MacroMoleculeBuilder, but as long as there is no released version of openmm with proper shared library versioning support, you/Debian could just ship a static dev library to use. That makes tracking API/ABI changes your job, but if it for just one or two downstream packages, it is usually doable, provided openmm is not too much of a moving target.

As the current version in Debian testing/unstable is 7.4.0.491.gac5a8f71+dfsg-1, packaging 7.4.2 that way wouldn't be a problem. I haven't looked at the code or the build system in detail, though, so might be totally off with this.

This sounds good, thanks for pointing it out. OpenMM's CMakeLists.txt seems to have an option to build static library only, and that should really be sufficient for MacroMoleculeBuilder until the next stable release for OpenMM.

samuelflores commented 4 years ago

Guys,

MMB only uses OpenMM to generate neighborlists. This is done at the beginning of an MMB run, before the time integrator starts, to do things like figure out which atoms to include in a phyics-where-you-want-it "bubble." I use no other OpenMM features. I am thus perfectly happy with even a many-years-old release of OpenMM.

I don't know much about debian packages but -- does installing MMB really make OpenMM libraries visible to the user? I would have guessed any OpenMM users would have set their library paths to look elsewhere for OpenMM. Anywhere other than the MMB install directory.

Sam

mbanck commented 4 years ago

I assume MMB usese the OpenMM libraries and does not run some OpenMM binary?

I don't know much about debian packages but -- does installing MMB really make OpenMM libraries visible to the user? I would have guessed any OpenMM users would have set their library paths to look elsewhere for OpenMM. Anywhere other than the MMB install directory.

If both MMB and OpenMM are installed via Debian packages, MMB would either include the OpenMM static libraries in its executable or would dynamically link to the OpenMM libraries in its executable. Both would be installed in the respective system paths, like /usr/bin and /usr/lib/x86_64-linux-gnu/

samuelflores commented 4 years ago

Ah I see.

Yes, MMB uses OpenMM libraries rather than executables. Linking is dynamic. I could go with static, since you said that would fix the issue. It's not clear to me how that fixes the issue, but I believe you.

We could also just decide on a supported past release of OpenMM, to be linked to by MMB. As I say that would also be easy. Is there a reason for waiting until the next release? As I understand it, the version numbers required by debian would prevent any conflict with user installed versions of openmm. But like I say your other proposed solution is fine by me, My objective is to avoid spending months waiting for future releases when the old release works fine.

sam