Ability to build 3.80

[lunarfs]

Removing jdk from package as it is installed as a dependeny.
Complying with new naming scheme.
Remove EMBEDDED_JDK lookup as it creates noise ,and we know we removed the jdk.
support downloaded nexus--linux-x86_64.tar.gz rather than nexus-unix-x86-64-.tar.gz

[dionysius]

What is needed to bring this PR forward? Please excuse the shy ping @bhamail

It has been a few months since this PR is open. The repository is missing packages since 3.70 which is a year now.

This PR works with 3.80.0-06 as well with the newest 3.82.0-08.

[bhamail]

I think at the very least, we should try to avoid reeking havoc on any existing installations of prior versions. The big problem is the old 3.7 versions could be chugging along with an old database, and get wedged if a user runs an updated installer that upgrades them to 3.8 series, which requires a new database, etc. If we could ensure the updated installer would "stop" and provide an error for such older versions (instead of doing a failed upgrade that leaves the system in an unusable state), I think that would be "good enough".

[dionysius]

Valid concern. I'm a bit familiar with debian packages, but right now don't know how much rpm differs. The core question also is what condition should qualify that the installation is allowed to happen.

In debian we have some options.

First the preinst stage (see flowchart for upgrade) is the correct place to make such a check as it allows to cancel the installation before anything is unpacked.

This check should also be combined with a version check <= the problematic version.

And finally, what kind of check is sufficient?

• maintainerscript promts: We can force a prompt to print text and require acknowledgement to continue with the upgrade. If prompting is not possible, we error the installation in all cases - so a manual confirmation has to happen. Also this looks like the debian-preferred approach for our reason:

  If a package has a vitally important piece of information to pass to the user (such as “don’t run me as I am, you must edit the following configuration files first or you risk your system emitting badly-formatted messages”), it should display this in the config or postinst script and prompt the user to hit return to acknowledge the message.

• We check for the (non-)existence of a problematic file, folder or config entry. Need help here since I don't know what we are looking for.
• We request a file to be placed at a specific path /opt/sona.../allow_upgrade_to_xxx before installation is invoked. The preinst checks for existence of this file and continues only if it exists.
• Can we migrate automatically? If the previous service runs we could invoke stuff here to do things automatically if feasible. Also works if migration requires stopped service to invoke migration if the service was stopped.

Lastly: is there a similar script to place such a check in yum packages?

[paul-botsco-2-0]

Thanks for the contribution. Unfortunately some of your commits don't meet our standards. All commits must be signed and have author information set.

The commits to review are:

• 9410d3a329e6c77e6d1e7733ad5964802abea0af - unsigned commit 🔑

See Signed Commits.