Rob Riggs's Journal: JPackage is Evil

I am leading a project at work where we are building components to extend an enterprise-scale software system. We are mostly a Sun shop. Most of the new components are being built to run primarily on Linux, Red Hat Enterprise Linux (AS3) to be exact. Some of the new components are being written in Java.

Most of the software installs for our in-house software is done using a rather archaic system and I want to do better on the Linux systems.

Being a long-time Linux user and admin, I wanted to make sure that we were managing our software installations and dependencies using the excellent package manager, RPM. When it came time to do the initial rollout of the first Java components, I looked around for pre-packaged components and was excited to find the JPackage Project. These guys have all of the most useful Sun and third-party Java software packaged up in RPM format.

I had no idea how evil these people were at the time.

Red Hat AS3 comes with its own set of Java components, including a JVM, ant (a common java build tool used to replace make) and a few others. The development servers seemed OK and the packages build. I installed the missing dependencies from the JPackage Project and everything was looking good. My workstation is a Fedora Core 1 box, so I had to install a few more components from JPackage on my machine than I did on the development servers.

I had all of the dependencies met for the software I was about to package up, and it took only a few minutes with wget and rpm to get there. I was ready to start building the package for the new software.

Here's where things start to go horribly wrong.

Ant would not work on my machine. I kept getting tracebacks about dependencies not being found. This was bizarre. Ant all worked on the development server. And ant worked on my workstation when run as root! I took me a while to look into all of the obvious potential causes: paths, environment, permissions, etc. Everything looked like it should work.

Then I decided to trace the script that instantiated the JVM and ran ant. It was setting different (and wrong!) environment variables. It was looking for its jar files in /opt/abacus, the location I have RPM configured (through my own .rpmmacros file) to use as the location to build packages for (the %_prefix). Why the hell was it doing that?

It took me a couple minutes looking at the the JPackage configuration system to discover, to my horror, that it was using the RPM build environemnt for runtime configuration. WTF?!? The RPM build environemnt is not a runtine configuration system. It is a build configuration system.

So now I am a bit disturbed that anyone would do such a thing. I sent an email to the person who built the ant RPM for the JPackage project:

I got your contact information from the JPackage RPM of Ant. I am trying to use Ant with RPM, but it seems to me that the Ant shell script that is provided with the RPM is doing some (IMHO) screwy things to set up its environment. It is invoking rpm to evaluate various rpm build variables to set up various environment variables. This completely breaks Ant when I need to change the %_prefix variable for RPM. The RPM build variables are just that: build variables. They have no relation to the runtime environment, which is what the Ant script is assuming. Do you know who is responsible for maintaining that script and how I can contact them?

This was forwarded to the JPackage mailing list and conversation ensued. There was at least one person who agreed with me about the problem, but the majority of responses were from the incredulous (saying I am doing something wrong) to the blasé.

The last quote in the thread were:

> I am still
> holding that %_bindir must be defined to `/usr/bin', and that if your
> build environment does not match your runtime environment then you're in
> serious trouble.
I agree. However it's not worth the arguing IMHO. Let people discover by
themselves the joys of using non-standard paths in a shared env.

And that, my friends, is just evil. Anyone who know RPM will know how evil that is. The JPackage developers do not understand RPM and are usurping it. This sort of attitude can harm RPM in the long run. And they don't care.