graphical installer, suggest: either explain "extra utilities", or drop the entry

[nbehrnd]

Is your feature request related to a problem? Please describe. Running the graphical installer for the current version 22.0.6 for Linuxes instead of the package manager of the OS' distribution (e.g., apt for Linux Debian 13/trixie), I notice the entry "extra utilities" (cf. screen photo below). One may toggle-on/off this one which (so far) apparently does not affect MOPAC's installation, nor functionality. Contrasting to anticipation, the installer does not provide a description what these are, what benefit in functionality they offer. Perhaps it is a remnant entry of something no longer shipped.

Describe the solution you'd like In future versions of the installer, either a) describe what this optional entry provides on the side right to the menue, similar to the graphical installer for Windows. Or b) drop this additional entry.

Describe alternatives you've considered Thanks to efforts by the DebiChem team, running an installation with the apt package manager.

Additional context

[godotalgorithm]

The "extra utilities" option should install two additional executables, mopac-param and mopac-makpol. These are not part of the typical usage of MOPAC, but they assist in using some of its more advanced features. These executables are both quite small in size and clearly labeled as related to MOPAC, so I might just switch to installing them by default rather than retaining "extra utilities" as an installer option. If I retain the option, then I will add more explanatory text.

Is there a preferred action from the perspective of Linux package management? If I install these additional executables by default, then perhaps it will make sense to also include them in future releases of MOPAC's Linux package as well.

I'm preparing an imminent new release of MOPAC right now, and I'll resolve this one way or another when I update the installers for the new release.

[nbehrnd]

Differences I observe for an installation either a) with the graphical installer provided here, or b) with apt package manager are the different paths the installation defaults to, /opt/mopac/ vs. /usr/bin/mopac. That's fine. For me, the preference for the approach moderated by apt only is because this eases to provide a setup based on a script. The GUI based approach however is helpful in ecosystems less frequently upgraded (with flavors of Ubuntu LTS 22.04/Jammy intended to run for 2 years, for example vs Debian 13/trixie which is of branch testing and already provides MOPAC 22.0.6).

• Contrasting to the GUI based installation, the one with apt in Debian 13 appears to skip mopac-makpol: tab completion of mopa on the CLI then yields only the suggestions mopac and mopac-param. Do you recommend I get in touch with the maintainers of DebiChem if mopac-makpol were accidentally lost while (re)packaging MOPAC, or is this a detail in control of MOPAC as project? Based on MAKPOL's documentation, the conversion of .pdb into MOPAC .dat input files, for example, appears to provide some similar functionality as conversions by openbabel.

• The call mopac yields a greeter including the last line Press (return) to continue, and one gets back by this one to the CLI. However, mopac-makpol (as provided by the graphical installer) requires either an explicit Ctrl + c, or Ctrl + z to leave the greeter. This can be observed both for Linux Debian 13/trixie, as Xubuntu 22.04 (for the later, a log attached below). Though so far I don't use MAKPOL, maybe a leave as gentle as for the greeter of mopac (and mopac-param) by a mere enter can be provided.

2023-09-11_example.txt

[godotalgorithm]

I agree that package managers should be the preferred installation method for MOPAC in the future, and I am trying to do what I can to funnel users in that direction (e.g. I am maintaining the multi-platform conda-forge distribution). I created and maintain the self-contained installers because that is in line with how MOPAC was distributed as a commercial product for 15 years, and I have an obligation to maintain that form of distribution as long as people are using it.

Feel free to notify the DebiChem people of the missing mopac-makpol program. I am not involved with them right now, and you are probably a lot more familiar with them than I am. MAKPOL is performing a structural transformation - it is unfolding the periodic unit cell of a crystal into a supercell - which isn't too complicated, but not something that OpenBabel can do at the moment as far as I'm aware. MAKPOL is much simpler than MOPAC and PARAM and may eventually be replaced by a Python script.

When I fix the installer issue, I will also add a push-button-to-exit function to MAKPOL's splash screen.

[nbehrnd]

To keep you or/and other developers of MOPAC aware, I filed a ticket for the addition of mopac-makpol in Debian's MOPAC package. The additional entry as whishlist, bug 1051716 links to this thread. I would like to inform you if maintainers of Debian (in general) / DebiChem (in particular) alter the status of the ticket; and hence kindly request to retain this thread open.

[nbehrnd]

For now, the license issue on mopac-makpol mentioned here prevented the inclusion in DebiChem's MOPAC package. With the advent of a new version of MOPAC, the obstacle is plausibly going to leave.

[godotalgorithm]

Ah yes, I remember that issue popping up, and I just didn't realize that there hadn't actually been any new releases since then. There haven't been any major bug fixes to warrant a patch-level release since then, and I've been waiting for the development of a new model to be finished and published before pushing out a new minor-version release. Now, I'm just waiting on some final fine-tuning of that new model before the release can actually occur.

[godotalgorithm]

The new version is released now, and the updated graphical installers no longer have the extra utilities as an option, all available MOPAC-related executables are now always installed.