On 28/11/07 23:26, Troy Dawson wrote:
> Hi All,
> We have a bit of a problem with java on SL4, and I believe most of you 
> know at least part of it.
> Our java rpm's come straight from Sun with no changes.  Even signing 
> them causes problems with the rpm.
> The 1.4.2 rpm that comes from sun, for some unkown reason, says that it 
> obsoletes jdk.  This means that when you update the j2sdk, it deletes 
> any jdk rpms an admin might have added even if it's newer.  So if I send 
> out an update to the current j2sdk for 1.4.2, it will delete the 1.5.0 
> java and/or the 1.6.0 java.
> 
> But I'm really hating not getting the security updates out for this java.
> 
> I see three options.
> 1 - We just push it out as it is, and say "sorry" to everyone this 
> hurts. (That's what we did last time ... and trust me, that's alot of 
> "sorry" I had to  say)
> 2 - We rebuild the j2sdk rpm, leaving out the obsolete line.
> 3 - We drop j2sdk and change our supported java to be version 1.5 and 
> above.
> 
> I am leaving heavily towards option 3.  Just move everything up to java 
> 1.5 or above.
> 
> But the question is, how much is that going to hurt people and/or 
> experiments?
> 
> I *think* that moving to jave 1.5 isn't going to affect programs running 
> 1.4.2, but I don't know.
> 
> Also, why stop at 1.5, what if we just did the latest 1.6, and maybe say 
> we're always going to stay at the latest stable release for java.
> 
> I need some second opinions.

here we go. Background is that we have our own J2RE-1.4 and JDK-1.5 
repackaged RPMs - only available within CERN since we never got any "OK 
to distribute" from SUN (but of course the .spec is free). These are 
loosely based on jpackage.org "nosrc".

* We haven't seen any issues from 1.5 with older (-1.4) programs so far. 
But our usage is somewhat limited (browser plugin, some simplistic 
apps). Most heavyweight Java users seem to have their own installation 
somewhere.

* the 1.4.2 RPMs from SUN are indeed broken, up to and including 
mismatch between RPM filename and metadata content - this screws some 
RPM tools that assume 
http://someplace/%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}.rpm should exist, 
just because the metadata is present. It used to affect YUM, not sure 
whether this is still the case.

* we have (ourselves) little experience with 1.6. 1.7/openjdk is not in 
usable form yet, but set to be getting there relatively soon since F8 
now comes with icedtea (a completely free instance of the 
partially-encumbered 1.7 JDK). I'd rather look at 1.7 since that will 
remove any lingering doubts about lawful redistribution.

My personal opinion would be to go for a repackaged 1.5 that properly 
obsoletes your previous version of 1.4.2 (but nothing else, to allow for 
parallel installs), and at the same time declare that you may change 
versions later. After all, this is not part of the release TUV SRPM set, 
so not as tightly bound to the "do not change" commitment.

Best regards
Jan