Development

Related Links

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.

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.

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,
folks!):[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:

%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.