Installer & Debian Packaging Discussion - openrocket/openrocket GitHub Wiki

Neil Weinstock Sat, Oct 27, 4:28 PM (7 days ago) For what it's worth: Here at work we have a critical Java app. After much discussion, we decided that we are not going to upgrade it to 1.9. For now we will con

Joe Pfeiffer [email protected] via lists.sourceforge.net Oct 27, 2018, 4:49 PM (7 days ago) to openrocket-devel

There are two major formats, .deb used by Debian and its descendants, and .rpm, used by RedHat and its descendants. Packaging for those two would handle almost everybody. It's been packaged for Debian before...

It looks like it might be easier at this point to package it as an AppImage, which works across all Linux distributions. The drawback is that the AppImage would include the whole jvm as part of it, which just seems like a huge amount of extra stuff.

And for yet another direction, is anyone familiar with Oracle's javapackager? ...

[Message clipped] View entire message

Neil Weinstock via lists.sourceforge.net Oct 27, 2018, 4:57 PM (7 days ago) to OpenRocket

Oracle's javapackager is how I created the packaged versions I distribute on TRF. For reference once again, here's the thread: https://www.rocketryforum.com/threads/openrocket-packaged-installers-for-windows-and-mac-to-solve-all-your-java-problems.143540/

For the Mac it's all you need. Works great.

For Windows, it requires an additional third-party component that creates the actual installer file; my dissatisfaction with it is based on the fact that the resulting installer leaves the EXE file in a hard-to-find place and doesn't create shortcuts. That is probably fixable, but at the time I was just happy to have made it work at all.

There are many additional 3rd-party Windows package installers.

Including the whole JVM is the solution, not a problem. It (almost) completely ends compatibility issues, and also allows users to not install system Java. Read that thread and see how happy folks are. And as a full-blown app, it behaves like an app, with the ability to put it in the dock (on the Mac), and stuff like that.

There would certainly be nothing wrong with continuing to make the jar file available on its own, but in the future I would first steer users to download the appropriate packaged installer.

Just MHO.

teyrana via lists.sourceforge.net Oct 27, 2018, 5:19 PM (7 days ago) to OpenRocket

Thats a good point. Packages are awesome :)

Plus, we do have a gentlemen who created a .deb, and I'd be happy to help him test it at the next release (I have a linux/ubunu box) (its also an issue somewhere in our issue backlog, fwiw)

So, at that rate, we could also build with java 9, and package for java 8, no?

Neil Weinstock via lists.sourceforge.net Oct 27, 2018, 5:27 PM (7 days ago) to OpenRocket

You can package with whatever version of the jvm you like. The end system won’t care either way.

I’m just saying it’s not clear if it would be worth targeting 1.9 at this point if it’s significant extra work. If it’s ready to go with 1.9, then package it with 1.9, why not.

Carlos Cássio Oliveira [email protected] via lists.sourceforge.net Oct 27, 2018, 7:51 PM (7 days ago) to openrocket-devel

Parabéns! Eu sou o Sr. Cássio, presidente do grupo amador CEFAB. Ele usou este excelente programa para projetar nossos foguetes. Parabéns a todos da equipe! Sucesso! Em sáb, 27 de out de 2018 às 19:27, Neil Weinstock [email protected] escreveu:

teyrana via lists.sourceforge.net Oct 27, 2018, 9:43 PM (7 days ago) to OpenRocket

<note: Discussion facilitated by google translate. Apologies for any errors!> / <nota: auxiliado pelo google translate. Desculpas por quaisquer erros!>

Infelizmente, meu português (ou brasileiro?) Não é bom (a conversa é principalmente em inglês).

Obrigado pelas palavras amáveis! Nós construímos isso para usuários como você, que usam para coisas incríveis!

Por favor, deixe-nos saber se você observar quaisquer irregularidades com o software, ou pedidos de novos recursos.

Felicidades, -Dan

Chris Mickelson via lists.sourceforge.net Oct 27, 2018, 11:03 PM (7 days ago) to OpenRocket

Sorry to be pedantic, but the packaged executable option is a workaround, not a solution. The main thing I don’t like is that it hides problems that should be addressed. WHY does it have issue A or B when run as a jar but NOT with the JVM from within the installer file? It’s still running as java bytecode in a JVM either way, but why does one magically “fix” things and the other not?

We have to ask what is the goal for distributing three or more packaged installers? To solely provide a simpler installation for the average Joe user? Then by all means. If it’s also to fix bugs somehow and not know why, that raises red flags for me.

Sent from Mail for Windows 10

From: Neil Weinstock [email protected] Sent: Saturday, October 27, 2018 4:56:48 PM To: OpenRocket development mailing list Subject: Re: [Openrocket-devel] [openrocket/openrocket] Update to Java 9+ (#464)

...

[Message clipped] View entire message

Carlos Cássio Oliveira [email protected] via lists.sourceforge.net Oct 28, 2018, 8:35 AM (6 days ago) to openrocket-devel

Thank you for your attention, we are at your disposal !! I need to buy a book to continue our projects. Can you send it to my group? No irregularity! Best current program, NO HERE, at the moment! A hug from your friend, Cássio- Grupo CEFAB. Em dom, 28 de out de 2018 às 01:03, Chris Mickelson [email protected] escreveu:

Neil Weinstock via lists.sourceforge.net Oct 28, 2018, 10:40 AM (6 days ago) to OpenRocket

On Sun, Oct 28, 2018 at 12:03 AM Chris Mickelson [email protected] wrote: Sorry to be pedantic, but the packaged executable option is a workaround, not a solution. The main thing I don’t like is that it hides problems that should be addressed. WHY does it have issue A or B when run as a jar but NOT with the JVM from within the installer file? It’s still running as java bytecode in a JVM either way, but why does one magically “fix” things and the other not?

That's a fair philosophical question. I can tell you that on TRF at least, I eventually got to the point where I simply directed anyone with any problems running OR to just try the packaged installers and see if it fixed the problem. And it did, for all except maybe one.

I did not at any point embark on an effort to understand why the plain JAR file wasn't working but the packaged installer was. I confess I would have a hard time working up the motivation to do so. Also I don't necessarily have the expertise to do so.

There are a number of substantial user experience advantages to the packaged installers, which IMHO are more than sufficient to making them the preferred means of distribution (we can go through the list if you like, maybe a worthwhile exercise if everyone is not 100% on board with this idea).

The fact that it also seems to fix some additional mysterious problems is either a bug or a feature, depending on your viewpoint.

teyrana via lists.sourceforge.net Oct 28, 2018, 2:39 PM (6 days ago) to OpenRocket

On Sun, Oct 28, 2018, 11:41 AM Neil Weinstock [email protected] wrote: On Sun, Oct 28, 2018 at 12:03 AM Chris Mickelson [email protected] wrote: Sorry to be pedantic, but the packaged executable option is a workaround, not a solution. The main thing I don’t like is that it hides problems that should be addressed. WHY does it have issue A or B when run as a jar but NOT with the JVM from within the installer file? It’s still running as java bytecode in a JVM either way, but why does one magically “fix” things and the other not?

...

As far as I can tell, the issue is simply that the jar isn't compatible with java 9 (or later).

Primarily, because of the class loader. Also because of dependencies being obsolete, superseded, or juat plain abandoned.

If you want to talk about bugs, u think we may need to rewrite the JarInJar ClassLoader... But that's totally independent of any packaging, and totally dependent on the executing JVM.

Bdale Garbee [email protected] via lists.sourceforge.net Attachments Oct 28, 2018, 9:34 PM (6 days ago) to Joe, openrocket-devel

Joe Pfeiffer [email protected] writes:

There are two major formats, .deb used by Debian and its descendants, and .rpm, used by RedHat and its descendants. Packaging for those two would handle almost everybody. It's been packaged for Debian before...

That was by me.

The problem is that building openrocket from source in a way that would yield a policy-compliant package got difficult because of the number of libraries that got pulled in over time that were not yet packaged in the distribution. So, I "punted", and now deliver an installer package that just downloads the pre-built jar and provides a launcher script to invoke it, along with enough dependency information to ensure enough Java is on the system.

If others are willing to help me get the dependent libs packages for Debian, I'd be thrilled to eventually get back to delivering an openrocket package built from source to Debian (and thus the entire .deb based ecosystem derived from it).

Attachments area

teyrana via lists.sourceforge.net Oct 29, 2018, 7:14 AM (5 days ago) to OpenRocket

Oh, that's interesting. I dodnt know it wasnt built from source.

What's the downside to just supplying the prebuilt jar?

Joe Pfeiffer [email protected] via lists.sourceforge.net Oct 29, 2018, 11:34 AM (5 days ago) to openrocket-devel

Bdale Garbee writes:

Joe Pfeiffer [email protected] writes:

There are two major formats, .deb used by Debian and its descendants, and .rpm, used by RedHat and its descendants. Packaging for those two would handle almost everybody. It's been packaged for Debian before...

That was by me.

The problem is that building openrocket from source in a way that would yield a policy-compliant package got difficult because of the number of libraries that got pulled in over time that were not yet packaged in the distribution. So, I "punted", and now deliver an installer package that just downloads the pre-built jar and provides a launcher script to invoke it, along with enough dependency information to ensure enough Java is on the system.

If others are willing to help me get the dependent libs packages for Debian, I'd be thrilled to eventually get back to delivering an openrocket package built from source to Debian (and thus the entire .deb based ecosystem derived from it).

I'm a little surprised you had a problem with unpackaged libraries -- I'm able to build from source on my Debian system (with openjdk) and run the resulting jar, and I don't remember that I've put any unpackaged Java libraries on my system. Do you have any recollection of what libraries were problematic? At one time I had Eclipse on my system, but so far as I know I have completely removed it. Could there be something on my system left over from that?

teyrana via lists.sourceforge.net Oct 29, 2018, 9:35 PM (5 days ago) to OpenRocket

"Works on my machine"

I kid, I kid! Fwiw, I use ubuntu as one of my development boxes (xubuntu 16.04 + openjdk8) and it runs fine on that... Until I installed openjdk9. Oops.

Joe Pfeiffer [email protected] via lists.sourceforge.net Oct 29, 2018, 9:49 PM (5 days ago) to openrocket-devel

Joking aside, does this mean that the necessary libraries have been pulled in to the distribution, so that problem has been resolved?

Joe Pfeiffer http://flare-rocketry.com/ Secretary, FLARE 577 575.496.3501 (C - preferred) NAR #91164 SR 575.525.2764 (H) TRA #15525 HPR Certification L2

...

[Message clipped] View entire message

Bdale Garbee [email protected] via lists.sourceforge.net Oct 30, 2018, 2:53 AM (4 days ago) to OpenRocket, Joe

There used to be a number of libraries in the source tree pulled from various places. They all needed to be separated out and packaged to meet Debian policy.

I haven't looked recently, but just because you can compile a checked out tree doesn't mean you're close to a policy compliant package...

Bdale Sent from my Android device with K-9 Mail. Please excuse my brevity.

teyrana via lists.sourceforge.net Oct 30, 2018, 6:58 AM (4 days ago) to OpenRocket

What kinda of stuff are we talking about to make it "debian compliant"? (Assuming we start from with a compiling version of OR)

Everything builds from source?
Jars go into /usr/local/lib/jar/?

Does this mean we'd end up packaging many of our dependencies themselves?

Joe Pfeiffer [email protected] via lists.sourceforge.net Oct 30, 2018, 10:37 AM (4 days ago) to OpenRocket

Ah, got it. I was thinking you meant other libraries that had to be installed, not libraries in the source tree. Hmm... wow, looks like there are 46 jars in the tree (not counting OpenRocket.jar) after a build. I had no idea there were that many.

Bdale Garbee [email protected] via lists.sourceforge.net Attachments Oct 30, 2018, 10:46 AM (4 days ago) to teyrana, OpenRocket

teyrana [email protected] writes:

Ok. I guess I stepped into it here. Packaging Java apps for Debian turns out to be hard, because of what I personally perceive as fundamental differences of philosophy/methodology about how dependencies are handled.

Let me start with just a touch of context. Debian packaging technology and related policy evolved to have a number of goals, including things like ensuring all installed software works well together, that security updates take the least effort to implement and distribute, etc. Particularly in the world of Linux-style shared libraries, one of the ways this manifests is policy saying that N different packages shouldn't embed N different copies of a common source library, but that library should be broken out and packaged such that there's 1 copy of the library on the system that the N packages can all depend on. In theory, this makes the application packages smaller, there's only one thing that has to be updated to implement a security or other bug fix, etc, and we all live happily ever after.

The challenge I discovered packaging OR and other Java apps is that it seems to be completely standard to drop .jar files of things you want to depend on into the source tree and build them into each app's resulting jar. Without any explicit mechanism for preferring already-installed system-wide copies of those libraries, and without any visible versioning mechanism. I "get it", that this makes it easier to build the package across multiple target platforms without having to worry about what does and doesn't already exist where... but it's strongly counter to Debian packaging philosophy/policy. And therein lies the rub!

What kinda of stuff are we talking about to make it "debian compliant"? (Assuming we start from with a compiling version of OR)

I just took a quick look at the current git repo, and I count 43 .jar files embedded in the source tree. Without looking further, any of those used in building the Linux deliverable need to be looked at to see if a suitable version of that dependency is already packaged in Debian. Those that are not should be factored out and packaged, so that the openrocket source package build-depends on them instead of including them in the package source tree directly. See Debian policy 4.13, and other sections like 7.7:

https://www.debian.org/doc/debian-policy/

There's also an explicity Debian Java Policy that tries to translate main policy into Java-specific rules of engagement. See section 2.2, for example:

https://www.debian.org/doc/packaging-manuals/java-policy/

The last time I built a policy-compliant .deb from source, the number of in-tree .jar files was less than 10, and I "only" had to talk friends into helping me get one or two things packaged and added to Debian before I could successfully elide all of the .jar files from the source tree, turning them into build-depends specs, and get a working .jar out.

Everything builds from source?

Yes, of course.

Jars go into /usr/local/lib/jar/?

No. Packaged jars go to /usr/share/java. A Debian package should never deliver content to /usr/local.

Does this mean we'd end up packaging many of our dependencies themselves?

It certainly could, if nobody else has packaged them.

If this seems like a lot of work, then good, you've caught on to why I stopped trying to build a Debian openrocket package from source and moved to just delivering an installer that fetched the pre-built .jar. It turns out there are lots of folks "interested in" Java things working well in Debian, but few who seem motivated to just hunker down and package up a pile of dependent libraries, particularly since Java class libraries don't appear to have a strong versioning mechanism?

Having said that, I'd love to get back to packaging openrocket from source for Debian, and if enough energy is available here to help me work through the dependency chain... I'm game.

Attachments area

teyrana via lists.sourceforge.net Oct 30, 2018, 2:41 PM (4 days ago) to Bdale, OpenRocket

Oh, wow! That's an in depth explanation! Also, enough work to keep us busy for the next year. :P. But interesting, nonetheless!

I am curious about all that, though. We've been having a conversation at work about all this, so its useful to know :)

And for some reason, I thought .debs allowed binaries installs, but I wouldn't testify to it.

I do see your point, though. Thanks for bringing us up to speed :)

David Carter [email protected] via lists.sourceforge.net Oct 30, 2018, 3:05 PM (4 days ago) to OpenRocket, bdale

I’d be willing to package a few libraries if that would advance the cause. It’s been a while since I created any packages, but I’m sure I could polish up those skills. Are you willing to coordinate?