document MOPAC entry provided by DebiChem

[nbehrnd]

The documentation now hints to the package provided by DebiChem, as well as the survey by repology.org.

Status

• [x] Ready for merge

[nbehrnd]

The PR assumes the simultaneous hint to Debian/DebiChem (and hence, implicitly, the Ubuntu ecosystem) and to repology.org both provides a useful addition to the project's landing page, and retains the page easier to read than by addition of the long waterfall default badge by repology (link).

(It became only obvious while updating my fork of regiosqm which relies on MOPAC.)

[godotalgorithm]

I have a slight concern with the repology link, that it combines references to recent versions of MOPAC with an extremely old fork (MOPAC7). While this is a little confusing, at least the more recent version has a higher version number even though the version numbers do not refer to a common version history. I assume that this matter will naturally resolve itself as more Linux package managers switch to more up-to-date versions.

As you say, the vertical badge on repology is unacceptably large to add to the README file, but I wouldn't mind adding a 1-line badge with a link to repology such as the "latest packaged version" badge. I'll add this and do a bit of minor word-smithing before I accept your PR.

[nbehrnd]

@godotalgorithm Thank you for the additional perspective. With this in mind, it appears to be the safer approach to drop the link to repology.org for now. The reasoning is that Debian's package tracker has one entry mopac7 (link, last update by 2013-11-04) which is separate from mopac (link, first entry by 2023-01-27 about version 22.0.6) used in the PR.

Regarding repology.org, it then were sensible to get in touch with repology.org to request (in analogy to DebiChem) a new (separate) page (and badges) about contemporary MOPAC which originates from this GitHub page. Because it affects the visibility of MOPAC, I think it however is better left up to you/one of the project owners to file the petition to Dmitry Marakasov [amdmi3@amdmi3.ru](mailto:amdmi3@amdmi3.ru) to update repology.org accordingly (the report page already includes an option needs split).

[godotalgorithm]

I've posted a request to split the projects on the report page. I will accept your addition of the Debian package link for now, and I will consider adding in a badge/link to Repology after they've addressed my report. Thank you for bringing my attention to this matter.

[AMDmi3]

The idea behind merging mopac and mopac7 (and similar cases of new/outdated forks or branches) in Repology was to notify (old) MOPAC7 package maintainers that there's new version MOPAC. Even if these are not strictly interchangeable and directly related, it's handled gracefully, that is if a given repository only contains MOPAC7, it would be classified as outdated, but if it contains both MOPAC and MOPAC7, MOPAC7 would be classified as legacy, as can be seen here for two repositories:

Also it is quite common to drop numeric suffixes from name when packaging, so it's not unexpected for MOPAC7 to be packaged as mopac or vice versa, and it's simpler to keep these merged instead of splitting these. It's not the case for mopac/mopac7 though, at least for now.

If you think keeping these in the single entry is incorrect, I've unmerged these - it will be visible in a few hours.

As you say, the vertical badge on repology is unacceptably large to add to the README file

Note that you can float it like here: https://github.com/aristocratos/btop

[nbehrnd]

@AMDmi3 Thank you for the fast reply. For me (influenced by DebiChem's approach), the separate presentation of MOPAC7 and MOPAC is more sensible: If one starts to type mopac on Debian's package search tracker, JavaScript (?) provides suggestions to both, and then parts the ways. (Remotely, it carries some similarity to the story around GAMESS (UK), GAMESS (US), PC GAMESS/Firefly which aren't anymore 1:1 compatible among each other either.)

I didn't consider to arrange the badge sideways to the text. Though again eventually a decision at discretion of the maintainers, with currently about 450 px height (including the Linuxes most frequently seen engaged in quantum chemistry) it were only a little bit taller than the current section «installation» on the project's landing page:

Let's see.

[AMDmi3]

BTW, if you care for height, it can also be arranged into multiple columns. And you can also hide EoLed distros (only fedora 35 and 36 in this case, but it will also somewhat prevent the badge from growing).

[godotalgorithm]

@AMDmi3 I also appreciate the unexpectedly fast turnaround. This situation is a little bit like GAMESS, but in this case the main path of MOPAC's development has been much more active than any of its forks. The most active open-source fork of MOPAC is Don Truhlar's fork of MOPAC5, which has its own novel set of extra features reflecting the activity of the Truhlar research group. MOPAC5 is not available on any Linux package managers at the moment, but if it were added, then it would certainly make sense to keep it separate from the main MOPAC project. It is a bit unfortunate that these different efforts are only distinguished by an old major version number that was merged into the software name, but that is what happened.

I'll test various ways of adding in the vertical badge, including floating it, splitting it into multiple columns, and adjusting its location in the README file.