9:42 p.m.
I just installed Fedora Core 4, and happily, it seems to have all
the Java packages already installed for me and ready to go (during
the install I selected the Java and Eclipse packages, and also dev
tools packages).
Then, later, I noticed this site: http://jpackage.org/
They seem to have many of the same packages that already come
with FC4, and they're rpm's too.
At first I assumed that jpackage.org must be for other rpm-based
distros besides Fedora, but then I came across this article:
http://fedoranews.org/mediawiki/index.php/JPackage_Java_for_FC4
by Paul Howarth. It says:
|
| Fedora Core 4 users should use either the RPM from jpackage.org
| or manually install the Sun Java tarball into /opt. Sun Java 1.5+
| is recommended for stability purposes.
|
What are they talking about? FC4 already comes with Java:
[john@localhost ~]$ yum list | grep gcj
java-1.4.2-gcj-compat.i386 1.4.2.0-40jpp_31rh.FC4 installed
java-1.4.2-gcj-compat-devel.i386 1.4.2.0-40jpp_31rh.FC4 installed
java-1.4.2-gcj-compat-src.i386 1.4.2.0-40jpp_31rh.FC4 installed
libgcj.i386 4.0.0-8 installed
libgcj-devel.i386 4.0.0-8 installed
libgcj-src.i386 4.0.0-8 installed
java-1.4.2-gcj-compat-debuginfo.i386 1.4.2.0-40jpp_31rh.FC4 updates-released
Why would I install Java from jpackage.org when it already comes with
FC4 and works right OOTB?
Should FC4 users be using *any* packages from jpackage.org?
Thanks,
---John
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
4:27 a.m.
On Lun 25 juillet 2005 04:42, John M. Gabriele wrote:
Should FC4 users be using *any* packages from jpackage.org?
jpackage.org is a kind of upstream for FC java packages. JPP was born a
few years ago when there was no free Java stack and no distro was
seriously packaging java apps. Several users of rpm distributions got
together to package Java software in an rpm format.
One of our cunning decisions was to be JVM agnostic. When gcj matured Red
Hat was able to take our packages and use them with little changes in
Fedora. There is a strong wish both Red Hat and Fedora side not to break
this flow, so the JPP and FC java repositories should be compatible
(indeed, several JPP members are active on FE or even joined Red Hat, and
several Red Hat employees were accepted in the JPP team early this year).
The FC java stacks follows JPP packaging conventions.
JPP serves as an incubator : you can package java software that depends on
non-free java bits, or java software Red Hat is not interested in, and
when the conditions change (non-free bits get reimplemented in classpath
or interest arises) the package finds its way in FC. That also means some
software is only available in JPP today, and JPP is not pure FOSS (meaning
the answer to your original question depends on what exactly you want to
achieve).
Also JPP is open to packagers from all the rpm world (RHEL, FC, Mdk,
Novell, Solaris, OpenPKG...). We try not to depend on a particular
distribution quirk so the same packages work as-is everywhere. The team
has never been big and we've never rejected anyone.
Regards,
--
Nicolas Mailhot
11:16 p.m.
--- Nicolas Mailhot <nicolas.mailhot(a)laposte.net> wrote:
On Lun 25 juillet 2005 04:42, John M. Gabriele wrote:
> Should FC4 users be using *any* packages from jpackage.org?
jpackage.org is a kind of upstream for FC java packages. JPP was born a
What does the acronym "JPP" stand for?
few years ago when there was no free Java stack and no distro was
seriously packaging java apps. Several users of rpm distributions got
together to package Java software in an rpm format.
One of our cunning decisions was to be JVM agnostic. When gcj matured Red
Hat was able to take our packages and use them with little changes in
Fedora. There is a strong wish both Red Hat and Fedora side not to break
this flow, so the JPP and FC java repositories should be compatible
(indeed, several JPP members are active on FE
FE?
or even joined Red Hat, and
several Red Hat employees were accepted in the JPP team early this year).
The FC java stacks follows JPP packaging conventions.
JPP serves as an incubator : you can package java software that depends on
non-free java bits, or java software Red Hat is not interested in, and
when the conditions change (non-free bits get reimplemented in classpath
or interest arises) the package finds its way in FC. That also means some
software is only available in JPP today, and JPP is not pure FOSS (meaning
the answer to your original question depends on what exactly you want to
achieve).
Also JPP is open to packagers from all the rpm world (RHEL, FC, Mdk,
Novell, Solaris, OpenPKG...). We try not to depend on a particular
distribution quirk so the same packages work as-is everywhere. The team
has never been big and we've never rejected anyone.
Regards,
--
Nicolas Mailhot
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
6 a.m.
Nicolas Mailhot wrote:
FC = Fedora Core
FE = Fedora Extras
JPP = JPackage
Wouldn't it be simpler eg to say JPackage rather than JPP?
The latter only saves 5 key presses ...
--
Timothy Murphy
e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie
tel: +353-86-2336090, +353-1-2842366
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
9:26 a.m.
--- Nicolas Mailhot <Nicolas.Mailhot(a)laPoste.net> wrote:
FC = Fedora Core
FE = Fedora Extras
JPP = JPackage
--
Nicolas Mailhot
I was asking about that 2nd 'P':
JPP == Java Package Project
?
:)
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
9:33 a.m.
"John M. Gabriele" <john_sips_tea(a)yahoo.com> wrote:
I was asking about that 2nd 'P':
JPP == Java Package Project
Yes (and it was also probably preferred to have a three-letter acronym instead
of two).
--
Sincerely,
David Walluck
<david(a)zarb.org>
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
10:06 a.m.
On Mar 26 juillet 2005 16:26, John M. Gabriele wrote:
--- Nicolas Mailhot <Nicolas.Mailhot(a)laPoste.net> wrote:
> FC = Fedora Core
> FE = Fedora Extras
> JPP = JPackage
>
> --
> Nicolas Mailhot
>
I was asking about that 2nd 'P':
JPP == Java Package Project
The "official" name is the JPackage Project
--
Nicolas Mailhot
10:24 a.m.
On Mar 26 juillet 2005 17:06, Nicolas Mailhot wrote:
On Mar 26 juillet 2005 16:26, John M. Gabriele wrote:
> --- Nicolas Mailhot <Nicolas.Mailhot(a)laPoste.net> wrote:
>
>> FC = Fedora Core
>> FE = Fedora Extras
>> JPP = JPackage
>>
>> --
>> Nicolas Mailhot
>>
>
> I was asking about that 2nd 'P':
> JPP == Java Package Project
The "official" name is the JPackage Project
(using the J* word would have led to interesting legal consequences)
As for why this and not something else - frankly the team is small enough
we have better things to do than argue on naming.
In fact team size is our biggest constraint. This is why we do not do
package derivatives tailored to a particular distribution. All the
attempts to do this in the past have failed because frankly it's much less
ressource-intensive to just use as-is packages made under other
distributions than personalise them and rebuild the whole repository. We
strive for the good-enough not the perfect. If someday we have the
manpower of Mandrake club, Fedora Extras (or any project where the number
of active packagers at any given point of time is in the two-digit range
or more) this may change. Right now we have LSBish practical rules to
ensure vanilla packages build/run everywhere.
--
Nicolas Mailhot
10:47 a.m.
And BTW while JPackage certainly can "eat your brainz" more often than
Fedora Core, it's a not an absolute evil anymore than FE or FC are. In
terms of absolute package stability you certainly have
RHEL > FC > FE >= JPP (reflecting the size of the packaging and QA teams)
but you also need to think in terms of application span. Starting from a
package other people QAd is always less dangerous than playing with zips
and tar.gz all by yourself. If you really have the time and motivation to
make any given package better why the project accepts contributions. I
doubt you'll find the resources to repackage everything from scratch. Most
of the core packages took _many_ iterations to get to the stage they are
today (not that there is not a lot of work to do still)
--
Nicolas Mailhot
6:52 a.m.
On Sun, 24 Jul 2005 19:42:33 -0700, John M. Gabriele wrote:
Why would I install Java from jpackage.org when it already comes
with
FC4 and works right OOTB?
Because gcj (the GNU compiler for Java), which is the only implementation
of Java that comes with FC4, is not yet fully implemented. Most
importantly, it does not fully implement either AWT or Swing - the
graphical user interface systems which most graphical Java applications
use.
However, the Java apps and libraries shipped as part of FC4 (eclipse, ant,
xerces etc.) should work fine on the gcj platform. Please file bugs if
they do not.
This should be documented somewhere.
--
Robin
7:18 a.m.
Robin Green writes:
On Sun, 24 Jul 2005 19:42:33 -0700, John M. Gabriele wrote:
> Why would I install Java from jpackage.org when it already comes with
> FC4 and works right OOTB?
Because gcj (the GNU compiler for Java), which is the only implementation
of Java that comes with FC4, is not yet fully implemented. Most
importantly, it does not fully implement either AWT or Swing - the
graphical user interface systems which most graphical Java applications
use.
It's not just that. Just as significant is that fact that a lot of
applications depend on the internal details of a particular
implementation. In theory applications written in the Java language
are portable, but in practice it often doesn't work out that way.
Oh, and gcj has a different set of bugs from other implementations.
I'd better mention that too...
Andrew.
9:24 a.m.
--- Robin Green <greenrd(a)presidium.org> wrote:
On Sun, 24 Jul 2005 19:42:33 -0700, John M. Gabriele wrote:
> Why would I install Java from jpackage.org when it already comes with
> FC4 and works right OOTB?
[snip]
This should be documented somewhere.
I've *just* begun working on it:
http://www.simisen.com/jmg/pmwiki/pmwiki.php?n=Main.JavaOnFedora
(nothing there yet though)
BTW, for wiki software, I highly recommend PmWiki. Last night I tried
TWiki, phpwiki, qwikiwiki, then finally settled on PmWiki. Good docs,
easy to install and configure, GPL'd, generous and active user community,
clean and simple look.
---John
__________________________________
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html
7:48 a.m.
John M. Gabriele wrote:
Should FC4 users be using *any* packages from jpackage.org?
Yes, if you want to use JREs and SDKs other than the one we ship.
And also yes if you want to use Java applications other than the
ones we ship.
However, FC4 users should be careful about upgrading packages when
such an upgrade would result in a Fedora package being replaced with
a JPackage one. Doing this will in many cases cause you to lose
performance and/or function when using our JRE.
In short, update from JPackage's yum repository at your peril.
Cheers,
Gary
7:48 a.m.
Gary Benson wrote:
Yes, if you want to use JREs and SDKs other than the one we ship.
And also yes if you want to use Java applications other than the
ones we ship.
However, FC4 users should be careful about upgrading packages when
such an upgrade would result in a Fedora package being replaced with
a JPackage one. Doing this will in many cases cause you to lose
performance and/or function when using our JRE.
In short, update from JPackage's yum repository at your peril.
And therein lies a problem. As you say, there are valid reasons for
using JPackage RPMs on Fedora Core 4, but doing so is "perilous".
It would be a very good thing, IMNSHO, if the Fedora Java folks and the
JPackage folks could develop some sort of co-existance strategy.
--
========================================================================
Ian Pilcher i.pilcher(a)comcast.net
========================================================================
8:07 a.m.
Ian Pilcher <i.pilcher(a)comcast.net> wrote:
It would be a very good thing, IMNSHO, if the Fedora Java folks and
the
JPackage folks could develop some sort of co-existance strategy.
I don't think that there are any major issues with co-existence. The
idea, as I
gather from the list, was always to have FC4 be ``fully'' jpp-compatible.
The major issue I see is that the .so files and other binaries aren't shipped
separately. I never did catch the exact reason for this. This means
that if you
run a jpp package on gij then it may run slower because it hasn't been
natively
compiled. The upside of shipping the .so files separately is that you don't
have to lose them if you use a jpp package, and you don't have to turn every
nice noarch package into an arch package just to get the .so files. As I
understand it, it takes much too long to compile the libs on the fly (ideally
what I wish could be done), but that doesn't preclude the existence of
separate
binary packages that would depend on the noarch packages.
The other major issue I see is that sometimes the free packages are missing
functionality (due to either license restrictions or actual missing
functionality in the free stacks), and these jars aren't split in such a way,
either, that you would know what you were missing (not that this is
even really
feasible).
--
Sincerely,
David Walluck
<david(a)zarb.org>
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
8:38 a.m.
David Walluck wrote:
Ian Pilcher <i.pilcher(a)comcast.net> wrote:
> It would be a very good thing, IMNSHO, if the Fedora Java folks
> and the JPackage folks could develop some sort of co-existance
> strategy.
I don't think that there are any major issues with co-existence. The
idea, as I gather from the list, was always to have FC4 be ``fully''
jpp-compatible.
The major issue I see is that the .so files and other binaries
aren't shipped separately. I never did catch the exact reason for
this.
There's a multitude of reasons. The biggest showstopper of them all
(from my point of view) is that there's no way to cause the native
stuff to be installed automatically. Someone who did 'yum install
tomcat5' would have a very slow Tomcat if they did not know to run
'yum install tomcat-gcjlibs' or whatever.
This means that if you run a jpp package on gij then it may run
slower because it hasn't been natively compiled. The upside of
shipping the .so files separately is that you don't have to lose
them if you use a jpp package,
You would lose them unless the JPackage package was compiled with the
same compiler as the Fedora one since Native code is located using the
MD5 of the bytecode.
As I understand it, it takes much too long to compile the libs on
the fly (ideally what I wish could be done),
Yes. Hours in the case of big packages like JacORB and Xalan. You
also need an incredible amount of memory, although aot-compile-rpm
mitigates this somewhat.
The other major issue I see is that sometimes the free packages are
missing functionality (due to either license restrictions or actual
missing functionality in the free stacks)
That's not such a problem these days, except where packages use Sun-
specific classes. A bigger problem is that the Fedora rpms often
contain workarounds for libgcj issues. Upgrading to the JPackage
loses those workarounds.
Cheers,
Gary
8:42 a.m.
Gary Benson writes:
David Walluck wrote:
> Ian Pilcher <i.pilcher(a)comcast.net> wrote:
> > It would be a very good thing, IMNSHO, if the Fedora Java folks
> > and the JPackage folks could develop some sort of co-existance
> > strategy.
>
> I don't think that there are any major issues with co-existence. The
> idea, as I gather from the list, was always to have FC4 be ``fully''
> jpp-compatible.
>
> The major issue I see is that the .so files and other binaries
> aren't shipped separately. I never did catch the exact reason for
> this.
There's a multitude of reasons. The biggest showstopper of them all
(from my point of view) is that there's no way to cause the native
stuff to be installed automatically. Someone who did 'yum install
tomcat5' would have a very slow Tomcat if they did not know to run
'yum install tomcat-gcjlibs' or whatever.
Precompiled binaries are bug, so adding the jars to the same RPM as
the binaries makes not a huge difference to the total size.
Andrew.
9:48 a.m.
Andrew Haley wrote:
Andrew Haley writes:
>
> Precompiled binaries are bug, so adding the jars to the same RPM
> as the binaries makes not a huge difference to the total size.
Argh! Precompiled binaries are *big*.
Erm, that's kind of backward. The native code is roughly four times
the size of the bytecode, so our rpms are five times the size of their
corresponding JPackage ones. Uncompressed, at any rate.
Cheers,
Gary
9:54 a.m.
Gary Benson writes:
Andrew Haley wrote:
> Andrew Haley writes:
> >
> > Precompiled binaries are bug, so adding the jars to the same RPM
> > as the binaries makes not a huge difference to the total size.
>
> Argh! Precompiled binaries are *big*.
Erm, that's kind of backward. The native code is roughly four times
the size of the bytecode, so our rpms are five times the size of their
corresponding JPackage ones. Uncompressed, at any rate.
Right, so there's no point omitting the jars from the RPMs that
contain the precompiled code.
Andrew.
9:33 a.m.
--- David Walluck <david(a)zarb.org> wrote:
Ian Pilcher <i.pilcher(a)comcast.net> wrote:
> It would be a very good thing, IMNSHO, if the Fedora Java folks and the
> JPackage folks could develop some sort of co-existance strategy.
I don't think that there are any major issues with co-existence. The
idea, as I
gather from the list, was always to have FC4 be ``fully'' jpp-compatible.
The major issue I see is that the .so files and other binaries aren't shipped
separately. [snip]
Could you please explain what shared libs have to do with Java packages here?
What do you mean by .so files being shipped separately? Don't Java packages
just come with either:
1. jar files that consist of bundled-up .class files, or
2. binaries built with GCJ that link with the libgcj already on your system?
Since JPP packages are JVM-agnostic, then wouldn't that rule out #2
above for JPP packages?
Thanks,
---J
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
9:39 a.m.
John M. Gabriele writes:
--- David Walluck <david(a)zarb.org> wrote:
> Ian Pilcher <i.pilcher(a)comcast.net> wrote:
>
> > It would be a very good thing, IMNSHO, if the Fedora Java folks and the
> > JPackage folks could develop some sort of co-existance strategy.
>
> I don't think that there are any major issues with co-existence. The
> idea, as I
> gather from the list, was always to have FC4 be ``fully'' jpp-compatible.
>
> The major issue I see is that the .so files and other binaries aren't shipped
> separately. [snip]
Could you please explain what shared libs have to do with Java packages here?
What do you mean by .so files being shipped separately? Don't Java packages
just come with either:
1. jar files that consist of bundled-up .class files, or
2. binaries built with GCJ that link with the libgcj already on your system?
Since JPP packages are JVM-agnostic, then wouldn't that rule out #2
above for JPP packages?
For Fedora it's not either/or: it's both.
Andrew.
9:58 a.m.
John M. Gabriele wrote:
--- David Walluck <david(a)zarb.org> wrote:
> Ian Pilcher <i.pilcher(a)comcast.net> wrote:
>
> > It would be a very good thing, IMNSHO, if the Fedora Java folks
> > and the JPackage folks could develop some sort of co-existance
> > strategy.
>
> I don't think that there are any major issues with co-existence.
> The idea, as I gather from the list, was always to have FC4 be
> ``fully'' jpp-compatible.
>
> The major issue I see is that the .so files and other binaries
> aren't shipped separately. [snip]
Could you please explain what shared libs have to do with Java
packages here?
What do you mean by .so files being shipped separately? Don't Java
packages just come with either:
1. jar files that consist of bundled-up .class files, or
2. binaries built with GCJ that link with the libgcj already on your
system?
Java packages in Fedora (since FC4) always contain jar files.
Sometimes they also contain native code shared libraries for libgcj.
Cheers,
Gary
8:24 a.m.
Ian Pilcher wrote:
Gary Benson wrote:
> Yes, if you want to use JREs and SDKs other than the one we ship.
> And also yes if you want to use Java applications other than the
> ones we ship.
>
> However, FC4 users should be careful about upgrading packages when
> such an upgrade would result in a Fedora package being replaced
> with a JPackage one. Doing this will in many cases cause you to
> lose performance and/or function when using our JRE.
>
> In short, update from JPackage's yum repository at your peril.
And therein lies a problem. As you say, there are valid reasons for
using JPackage RPMs on Fedora Core 4, but doing so is "perilous".
Yes, though again it's only a problem if you replace Fedora packages
with JPackage ones. Installing packages from JPackage that do not
exist in Fedora should pose no problems.
It would be a very good thing, IMNSHO, if the Fedora Java folks and
the JPackage folks could develop some sort of co-existance strategy.
We do coexist. Unfortunatly the limitations of rpm's linear version
space mean that something has to give, and that something is
upgrading.
Cheers,
Gary
9:35 a.m.
Gary Benson wrote:
Ian Pilcher wrote:
>Gary Benson wrote:
>
>>In short, update from JPackage's yum repository at your peril.
>
>And therein lies a problem. As you say, there are valid reasons for
>using JPackage RPMs on Fedora Core 4, but doing so is "perilous".
Yes, though again it's only a problem if you replace Fedora packages
with JPackage ones. Installing packages from JPackage that do not
exist in Fedora should pose no problems.
So I can install Sun's JDK via JPackage, develop a web application, and
be sure that it will run on Fedora's Tomcat?
>It would be a very good thing, IMNSHO, if the Fedora Java folks and
>the JPackage folks could develop some sort of co-existance strategy.
We do coexist. Unfortunatly the limitations of rpm's linear version
space mean that something has to give, and that something is
upgrading.
Yeah, God knows I'm no RPM fanboy. I can think of a few possible
strategies:
1. Move all of Fedora's JPackage-compatible/alternative packages into a
separate Yum repository (fedora-java{,-devel,-updates,-testing}
etc.). Users could them choose between JPackage and Fedora Java
packages by enabling/disabling appropriate repositories.
2. JPackage could create specially named packages for Fedora. For
example, tomcat5 could become jpp-tomcat5 or somesuch. Obviously,
jpp-tomcat5 would have to provide "tomcat5", and dependency
resolvers such as Yum might still mess things up; installing a
JPackage RPM might pull in a Fedora package, for example.
3. Yum could be enhanced to give more control to system administrators.
It might be possible, for example, to configure Yum to "prefer"
packages from a particular repository regardless of their EVR.
Just thinking out loud...
--
========================================================================
Ian Pilcher i.pilcher(a)comcast.net
========================================================================
10:54 a.m.
On Mar 26 juillet 2005 16:35, Ian Pilcher wrote:
Gary Benson wrote:
> Ian Pilcher wrote:
>
>>Gary Benson wrote:
>>
>>>In short, update from JPackage's yum repository at your peril.
>>
>>And therein lies a problem. As you say, there are valid reasons for
>>using JPackage RPMs on Fedora Core 4, but doing so is "perilous".
>
>
> Yes, though again it's only a problem if you replace Fedora packages
> with JPackage ones. Installing packages from JPackage that do not
> exist in Fedora should pose no problems.
>
So I can install Sun's JDK via JPackage, develop a web application, and
be sure that it will run on Fedora's Tomcat?
So you can develop and package an app, and (provided you've followed the
rules) people can change the implementation of your all your app
dependencies without needing to change your package.
This means switching from Sun JVM to gcj, changing XML parsers, etc.
Of course this is only at the package level. You still need to do some QA
to check you're not hitting a bug in the new dependency implementation
that wasn't there in the one you've used before. Build once, run
everywhere always actually meant build once, test everywhere.
--
Nicolas Mailhot
3:02 p.m.
On Tue, 26 Jul 2005 17:54:24 +0200, Nicolas Mailhot wrote:
> So I can install Sun's JDK via JPackage, develop a web
application, and
> be sure that it will run on Fedora's Tomcat?
So you can develop and package an app, and (provided you've followed the
rules) people can change the implementation of your all your app
dependencies without needing to change your package.
Actually, no. Fedora's tomcat packages contain a native and a non-native
version. The native version only works with libgcj, which is not 100%
compatible with Sun's Java. That's an important caveat, I think.
--
Robin
9:22 p.m.
Robin Green wrote:
On Tue, 26 Jul 2005 17:54:24 +0200, Nicolas Mailhot wrote:
>So you can develop and package an app, and (provided you've followed the
>rules) people can change the implementation of your all your app
>dependencies without needing to change your package.
Actually, no. Fedora's tomcat packages contain a native and a non-native
version. The native version only works with libgcj, which is not 100%
compatible with Sun's Java. That's an important caveat, I think.
I suspected as much. I believe that this situation should be addressed,
if possible.
--
========================================================================
Ian Pilcher i.pilcher(a)comcast.net
========================================================================
3:48 a.m.
Robin Green wrote:
On Tue, 26 Jul 2005 17:54:24 +0200, Nicolas Mailhot wrote:
> > So I can install Sun's JDK via JPackage, develop a web
> > application, and be sure that it will run on Fedora's Tomcat?
>
> So you can develop and package an app, and (provided you've
> followed the rules) people can change the implementation of your
> all your app dependencies without needing to change your package.
Actually, no. Fedora's tomcat packages contain a native and a
non-native version. The native version only works with libgcj, which
is not 100% compatible with Sun's Java. That's an important caveat,
I think.
That's not true at all. All Java packages in Fedora should behave the
same whatever JVM you're using. If they don't then you've found a bug
that needs fixing.
Cheers,
Gary
12:58 p.m.
On Tue, 2005-07-26 at 14:24 +0100, Gary Benson wrote:
Ian Pilcher wrote:
> Gary Benson wrote:
> > Yes, if you want to use JREs and SDKs other than the one we ship.
> > And also yes if you want to use Java applications other than the
> > ones we ship.
> >
> > However, FC4 users should be careful about upgrading packages when
> > such an upgrade would result in a Fedora package being replaced
> > with a JPackage one. Doing this will in many cases cause you to
> > lose performance and/or function when using our JRE.
> >
> > In short, update from JPackage's yum repository at your peril.
>
> And therein lies a problem. As you say, there are valid reasons for
> using JPackage RPMs on Fedora Core 4, but doing so is "perilous".
Yes, though again it's only a problem if you replace Fedora packages
with JPackage ones. Installing packages from JPackage that do not
exist in Fedora should pose no problems.
Well, great, *now* you tell me (a little late). The first thing I did
after I had FC4 set up was drop in the jpackage.repo, 'update', and then
install a bunch of stuff.
And what exactly is 'perilous'? Is this just a native compilation/speed
issue? Will everything still work, but slowly? Is this in every case,
and how do we know?
Would there be a way to put hooks into JPP SRPM's, or standardize on
their spec file formatting, in such a way that one could construct a yum
repository which *automatically* mirrors updates in the JPP yum repo,
downloading an updated SRPM, and rebuilding binary RPM's including the
shared lib with instructions to install it?
JPackage, supplying a jpackage.repo file and all, appears to be quite
conscious of being used on FC, so I certainly would not have expected
using it to break things. I don't recall seeing any big red letters
saying "DON'T USE THIS TO DO AN UPDATE" on their site, or in the FC4
release notes. In fact, the FC4 notes specifically mention using RPM's
from JPackage. I think a warning in section 6.1.8 would be in order, or
perhaps some form of grail-shaped beacon warning of this great peril ;)
And how do you use JPackage through yum while avoiding updates - what
happens when you install a JPP package with a dependency on another JPP
package which would update an FC4 version? If I need the 2.7.0 version
of Xerces from JPP to get DOM3 support, how do I not break my native
Tomcat?
Much Thanks.
--
Chris Hubick
mailto:chris@hubick.com
http://www.hubick.com/
6846
days inactive
6848
days old
java-devel@lists.fedoraproject.org
31 comments
10 participants
participants (10)
-
Andrew Haley -
Chris Hubick -
David Walluck -
Gary Benson -
Ian Pilcher -
John M. Gabriele -
Nicolas Mailhot -
Nicolas Mailhot
-
Robin Green -
Timothy Murphy