Deb package dependencies

[GreyCat]

It caught my attention that .deb packages which sbt-native-packager generates lacks any dependencies, even on the JRE (i.e. something like default-jre or may be even something that states minimal version needed, as, for example, nowadays Scala-build .class files require Java >=8 due to 52.0 class version).

Expected behaviour

apt-get install my-package installs all required stuff to make my-package build by sbt-native-packager work on Debian/Ubuntu.

Actual behaviour

Package installs, but trying to run it yields

No java installations was detected.
Please go to http://www.java.com/getjava/ and download

Information

• What sbt-native-packager are you using: 1.3.2
• What sbt version: 1.1.1
• What is your build system (e.g. Ubuntu, MacOS, Windows, Debian ): Debian
• What package are you building (e.g. docker, rpm, ...): deb
• What version has your build tool (find out with e.g. rpm --version):
• What is your target system (e.g. Ubuntu 16.04, CentOS 7): Debian / Ubuntu

[muuki88]

Thanks for your report 😀

We haven't set any defaults, because there is no good one IMHO. Packages and versions can vary in a wide range. This would mean we would break a lot of packages just by wrong defaults. You can add dependencies if you like, but you don't have to.

[GreyCat]

Could you provide an example of what could break exactly?

As far as I see, all Debian/Ubuntu repositories supply multiple JRE packages, but due to convention, all of them provide java-runtime package, or, if we'll need minimum Java 8, then java8-runtime. Even if one downloads an Oracle-supplies SDK and installs it using make-jpkg from java-package, it would still have these java-runtime, java5-runtime, java6-runtime, java7-runtime and java8-runtime in Provides.

The only concern I've found is that there are two "flavours" — javaX-runtime vs javaX-runtime-headless. This one should be decided by package's creator, based on his requirements (i.e. whether the application requires AWT / Swing / fancy UI stuff or not).

I understand that it's important to not break existing user's installations, but may be we could at least recommend adding debianPackageDependencies := "java8-runtime-headless" or debianPackageDependencies := "java8-runtime" in the docs, explaining the difference? I don't see any downsides of that.

[muuki88]

Sorry for my short reply 😀 Didn't meant to be round.

Could you provide an example of what could break exactly?

I can't. My concern comes from having no insights on how people configure their Debian packages. We have had a lot of interesting configurations.

For example some users try to ship their application along with an JRE, so this dependency would not be necessary.

Where would we add the JRE dependency? the JavaAppPackaging would be my first guess, but we don't know how the package is distributed. Maybe users can't install anything else, the JRE is provided somewhere else.

I understand that it's important to not break existing user's installations, but may be we could at least recommend adding debianPackageDependencies := "java8-runtime-headless" or debianPackageDependencies := "java8-runtime" in the docs, explaining the difference? I don't see any downsides of that.

That would be awesome 🤩 Would you like to open a pull request for this?

[GreyCat]

Well, if you'd ask me, I'd say that if user does not want to integrate into Debian/Ubuntu packaging environment (and would instead install JRE somehow manually), there is no point to use .deb packages in the first place. However, given that a app's owner needs to decide which JRE variant one requires (full or headless), there's still some manual work needed to specify that => probably a documentation template / recommendation solution would work the best.

That would be awesome 🤩 Would you like to open a pull request for this?

Will do, hang on!

[muuki88]

I fully agree with you, but I have seen too many weird stuff, a lot of newcomers that struggle with the complexity of their build/deploy or company restrictions that make basic things non-trivial.

Setting defaults, means maintaining them, and for a small open source project like sbt-native-packer the cost is often higher.

Thank you for taking the time to discuss this and helping to improve the sbt-native-packer documentation 😍

[GreyCat]

Submitted my attempt at documenting the situation as #1107 — please take a look?

[GreyCat]

Thanks for accepting! I believe that this issue is resolved then.

[muuki88]

Thanks for your time to add this 🤩