JPackage Frequently Asked Questions

Recent or Transient FAQs

What is in JPP 1.7 and JPP 5.0? Why two?

Because some packages require Java 5 (to run or to build or both), we had to give them their own 5.0 release. All packages in JPP 1.7 build and run with Java 1.4.2 (and most with Java 5 as well). JPP 5.0 works on top of JPP 1.7, and adds packages that depend on Java 5 or even replace some JPP 1.7 RPMs that need special configuration or to be rebuilt to run on JDK 5. So, to use JPP 5.0, you need to configure BOTH the 5.0 and the 1.7 repositories.

Why package xyz is not in JPP 1.7 (nor 5.0)?

Because there is nobody looking at that particular package and it was not a dependency of any of the ones that have active maintainers either. If you really need it let us know by asking in the list (remember that this is mostly volunteer work done in people's scarce free time, please). Better yet, why don't you volunteer to look after this package and perhaps some of its dependencies? New contributors are welcome.

Permanent FAQ

How do I start using JPackage?

1. Install 'jpackage-utils' if is not already in your system.
2. Install a JDK (read the Installation Instructions).
3. Configure an automatic dependency management tool like yum, apt or urpmi
4. Install the packages you want.

Really, it's that easy. But read the Installation Instructions, please.
The jpackage-utils package contains utilities shared by many other packages, so if you're looking for something to try out the access with, it would be a good choice.

Package foo requires bar, but bar isn't on your web site anywhere.

bar is probably a virtual dependency provided by one or more packages. Current examples of this are java-devel, jaxp_parser_impl, etc. If you use a dependency manager such as apt, yum, urpmi, etc. it will normally handle these types of issues for you. For more on dependency managers, and some search engines that have the capability of finding the dependencies, see the Documentation page.

If you insist installing manually (not recommended), use a RPM search engine to locate a package which provides the virtual dependency and install it.

What is with the non-free section?

The non-free section contains some vital/interesting applications that can not be redistributed as binaries due to licensing restrictions. The JPackage Project has made every reasonable effort to contact the various vendors and see if an agreement could be made to distribute binaries, but at least for now, the no source RPMs (.nosrc.rpm) has been determined to be the only legal method available.

There's something YOU can do about this: go vote for bug id 4680244 at Sun's bug parade.

What's a .nosrc.rpm? I installed foo.nosrc.rpm and nothing happened.

No source RPMs are shipped without the source (hence the name) and need to be rebuilt after the source is fetched. See the "Building nosrc RPMs" page for more info.

Can't we get around the hassle of no source RPMs using mechanism foo?

We have been discussing this quite a bit, and in the end it was determined that the "click-through" restrictions of things like the Sun JDK prevent anything but the no source RPM solution that is implemented. See the previous questions for a more detailed discussion.

Can I use the binaries or RPMs shipped by Sun, IBM, Blackdown, Mandriva, etc. instead of/with JPackage RPMs?

Yes and no. It might work, but since a lot of work has been placed into detailing dependencies and requirements for all JPackage RPMs, you'll have less headaches using the JPackage RPM for a given application. The various SDKs are good examples of this.

Why do all these packages require jpackage-utils?

jpackage-utils provides useful macros and directory structures so that the other packages work properly. We didn't make this package up to give you headaches. Honestly.

Why the hefty use of epochs?

RPM has a partially undefined mechanism for dealing with missing epoch definitions. The decision was that it was better to explicitly declare an epoch of zero than leave it undefined and at the mercy of whatever version of RPM the user is running.

I tried to install foo on Fedora Core 2, but got lots of error messages and/or things don't work.

Fedora Core 2 ships some Java/GCJ packages that don't work together with JPackage offerings. This issue should be fixed in Fedora Core 3, thanks to Red Hat's involvement in JPackage. How to solve this for your FC2 installation depends on your needs, so we cannot provide a universally applicable solution at the moment. Here are some pointers how some JPackage users are solving the problem (thanks for posting this information, folks!):
https://www.zarb.org/pipermail/jpackage-discuss/2004-October/011219.html
https://www.zarb.org/pipermail/jpackage-discuss/2004-October/011222.html
https://www.zarb.org/pipermail/jpackage-discuss/2004-October/011255.html
https://www.zarb.org/pipermail/jpackage-discuss/2004-October/011253.html

I tried rebuilding xyz.nosrc.rpm and got a load of error messages about debugfiles.

If you are using Red Hat Linux 9 (or the phoebe betas, and possibly rawhide) you may need to turn off rpm debugging. In your ~/.rpmmacros add the following line:

%debug_package %{nil}

See the Red Hat 9 release notes for more information about this feature.

I tried installing package foo and got an error about requiring /lib/lsb/init-functions

JPackage's packaging policy aims towards lsb and FHS compliance. Some older distributions - notably Red Hat Linux 7.2 and below and Mandrake 8.2 and below do not necessarily provide the necessary init functions. For later distribution releases you should install redhat-lsb or lsb-release for Mandrake.

Can I help?

Absolutely! Join the mailing lists, submit specs, or just download and test. All of these are useful functions, and the more people that do them the better JPackage can become. For information on the mailing lists, see the .Mailing Lists" page.