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
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.
How do I start using JPackage?
Install 'jpackage-utils' if is not already in your system.
Install a JDK (read the
Configure an automatic dependency management tool like
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.
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
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
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 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. There are some pointers how some JPackage
users are solving the problem (thanks for posting this information,
[JPackage-discuss] FAQ entry for Fedora Core 2 integration problems
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:
See the Red Hat 9 release notes for more information about this feature.
I tried installing package
foo and got an error about
JPackage's packaging policy aims towards
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.