If you have the epel repo installed and enabled during a yum update, you get java-1.6.0-openjdk-1.6.0.0-1.0.b12.el5.2 instead of the stock .b09 version. Is this intentional and desirable? I thought epel generally did not replace stock components with newer versions.
on 6-1-2009 9:43 AM Les Mikesell spake the following:
If you have the epel repo installed and enabled during a yum update, you get java-1.6.0-openjdk-1.6.0.0-1.0.b12.el5.2 instead of the stock .b09 version. Is this intentional and desirable? I thought epel generally did not replace stock components with newer versions.
Any third party repo has the potential to replace base files. That is why the priorities and the protectbase plugins were written.
Scott Silva wrote:
on 6-1-2009 9:43 AM Les Mikesell spake the following:
If you have the epel repo installed and enabled during a yum update, you get java-1.6.0-openjdk-1.6.0.0-1.0.b12.el5.2 instead of the stock .b09 version. Is this intentional and desirable? I thought epel generally did not replace stock components with newer versions.
Any third party repo has the potential to replace base files. That is why the priorities and the protectbase plugins were written.
Obviously they have the potential - and almost equally obviously an end user will have no idea what to choose even if they do have a tiny bit of control over yum (but no way to see where their existing version came from). But I thought that long ago I asked if epel would supply a newer Firefox or OpenOffice (back when it was needed and RHEL hadn't done it yet...) and someone replied that it would not be epel policy to overwrite stock packages. Was that not correct - or have things changed?
on 6-1-2009 10:49 AM Les Mikesell spake the following:
Scott Silva wrote:
on 6-1-2009 9:43 AM Les Mikesell spake the following:
If you have the epel repo installed and enabled during a yum update, you get java-1.6.0-openjdk-1.6.0.0-1.0.b12.el5.2 instead of the stock .b09 version. Is this intentional and desirable? I thought epel generally did not replace stock components with newer versions.
Any third party repo has the potential to replace base files. That is why the priorities and the protectbase plugins were written.
Obviously they have the potential - and almost equally obviously an end user will have no idea what to choose even if they do have a tiny bit of control over yum (but no way to see where their existing version came from). But I thought that long ago I asked if epel would supply a newer Firefox or OpenOffice (back when it was needed and RHEL hadn't done it yet...) and someone replied that it would not be epel policy to overwrite stock packages. Was that not correct - or have things changed?
EPEL was also asked if they could add a repo tag just so people knew where things came from. That didn't happen either, but much "discussion" did happen. As for EPEL policy, I guess you will have to ask them. Since it is Fedora packages being rebuilt, there is going to have to be some newer things being put in there.
On Mon, Jun 1, 2009 at 12:31 PM, Scott Silva ssilva@sgvwater.com wrote:
on 6-1-2009 9:43 AM Les Mikesell spake the following:
If you have the epel repo installed and enabled during a yum update, you get java-1.6.0-openjdk-1.6.0.0-1.0.b12.el5.2 instead of the stock .b09 version. Is this intentional and desirable? I thought epel generally did not replace stock components with newer versions.
Any third party repo has the potential to replace base files. That is why the priorities and the protectbase plugins were written.
On my CentOS 5 Desktop, when I added the EPEL repository, and gave it a very low priority, the number of excluded packages more than quadrupled. "1648 packages excluded due to repository priority protections"
Les Mikesell wrote:
If you have the epel repo installed and enabled during a yum update, you get java-1.6.0-openjdk-1.6.0.0-1.0.b12.el5.2 instead of the stock .b09 version. Is this intentional and desirable? I thought epel generally did not replace stock components with newer versions.
EPEL doesn't replace rhel5 packages, true, and afaict, openjdk isn't in rhel5. Perhaps a centos addon/extra?
-- Rex
Rex Dieter wrote:
Les Mikesell wrote:
If you have the epel repo installed and enabled during a yum update, you get java-1.6.0-openjdk-1.6.0.0-1.0.b12.el5.2 instead of the stock .b09 version. Is this intentional and desirable? I thought epel generally did not replace stock components with newer versions.
EPEL doesn't replace rhel5 packages, true, and afaict, openjdk isn't in rhel5. Perhaps a centos addon/extra?
-- Rex
That might have been true at one point in time but it isn't now. On a stock RHEL5.x you can say 'yum install java-1.6.0-openjdk' and you get a copy that appears to be built from what you find here: ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS/ and pretty much the same in CentOS - if you don't have epel enabled.
Les Mikesell wrote:
Rex Dieter wrote:
Les Mikesell wrote:
If you have the epel repo installed and enabled during a yum update, you get java-1.6.0-openjdk-1.6.0.0-1.0.b12.el5.2 instead of the stock .b09 version. Is this intentional and desirable? I thought epel generally did not replace stock components with newer versions.
EPEL doesn't replace rhel5 packages, true, and afaict, openjdk isn't in rhel5. Perhaps a centos addon/extra?
That might have been true at one point in time but it isn't now. On a stock RHEL5.x you can say 'yum install java-1.6.0-openjdk' and you get a copy that appears to be built from what you find here: ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS/ and pretty much the same in CentOS - if you don't have epel enabled.
I have a local centos5 mirror, and couldn't find openjdk rpms anywhere. wtf?
-- Rex
Les Mikesell wrote:
Rex Dieter wrote:
Les Mikesell wrote:
If you have the epel repo installed and enabled during a yum update, you get java-1.6.0-openjdk-1.6.0.0-1.0.b12.el5.2 instead of the stock .b09 version. Is this intentional and desirable? I thought epel generally did not replace stock components with newer versions.
EPEL doesn't replace rhel5 packages, true, and afaict, openjdk isn't in rhel5. Perhaps a centos addon/extra?
-- Rex
That might have been true at one point in time but it isn't now. On a stock RHEL5.x you can say 'yum install java-1.6.0-openjdk' and you get a
OK, found it, I'll go known some skulls @ epel.
-- Rex
Rex Dieter wrote:
If you have the epel repo installed and enabled during a yum update, you get java-1.6.0-openjdk-1.6.0.0-1.0.b12.el5.2 instead of the stock .b09 version. Is this intentional and desirable? I thought epel generally did not replace stock components with newer versions.
EPEL doesn't replace rhel5 packages, true, and afaict, openjdk isn't in rhel5. Perhaps a centos addon/extra?
-- Rex
That might have been true at one point in time but it isn't now. On a stock RHEL5.x you can say 'yum install java-1.6.0-openjdk' and you get a
OK, found it, I'll go known some skulls @ epel.
I'm not sure it's really a bad thing. For example OpenNMS claims it needs b12 or later. But it is curious that apparently no one noticed or knows which is better. Has the history of Linux distro treatment of java (shipping one that doesn't work and being unfriendly to the one that does) completely destroyed any interest?
Les Mikesell wrote:
Rex Dieter wrote:
If you have the epel repo installed and enabled during a yum update, you get java-1.6.0-openjdk-1.6.0.0-1.0.b12.el5.2 instead of the stock .b09 version. Is this intentional and desirable? I thought epel generally did not replace stock components with newer versions.
EPEL doesn't replace rhel5 packages, true, and afaict, openjdk isn't in rhel5. Perhaps a centos addon/extra?
-- Rex
That might have been true at one point in time but it isn't now. On a stock RHEL5.x you can say 'yum install java-1.6.0-openjdk' and you get a
OK, found it, I'll go known some skulls @ epel.
I'm not sure it's really a bad thing. For example OpenNMS claims it needs b12 or later. But it is curious that apparently no one noticed or knows which is better. Has the history of Linux distro treatment of java (shipping one that doesn't work and being unfriendly to the one that does) completely destroyed any interest?
Many people might not have noticed because they use yum priorities or apt pinning, as they should. Others might have noticed but ignored it as it is not a centos issue but an epel one, so there was nothing to report on this list. (Why it wasn't reported to epel is another question, but doesn't concern this list.)
Nicolas Thierry-Mieg wrote:
Les Mikesell wrote:
Rex Dieter wrote:
If you have the epel repo installed and enabled during a yum update, you get java-1.6.0-openjdk-1.6.0.0-1.0.b12.el5.2 instead of the stock .b09 version. Is this intentional and desirable? I thought epel generally did not replace stock components with newer versions.
EPEL doesn't replace rhel5 packages, true, and afaict, openjdk isn't in rhel5. Perhaps a centos addon/extra?
-- Rex
That might have been true at one point in time but it isn't now. On a stock RHEL5.x you can say 'yum install java-1.6.0-openjdk' and you get a
OK, found it, I'll go known some skulls @ epel.
I'm not sure it's really a bad thing. For example OpenNMS claims it needs b12 or later. But it is curious that apparently no one noticed or knows which is better. Has the history of Linux distro treatment of java (shipping one that doesn't work and being unfriendly to the one that does) completely destroyed any interest?
Many people might not have noticed because they use yum priorities or apt pinning, as they should.
Which one should get priority, and where is the appropriate place to learn that?
Les Mikesell wrote:
Nicolas Thierry-Mieg wrote:
Les Mikesell wrote:
Rex Dieter wrote:
> If you have the epel repo installed and enabled during a yum update, you > get java-1.6.0-openjdk-1.6.0.0-1.0.b12.el5.2 instead of the stock .b09 > version. Is this intentional and desirable? I thought epel generally > did not replace stock components with newer versions. EPEL doesn't replace rhel5 packages, true, and afaict, openjdk isn't in rhel5. Perhaps a centos addon/extra?
-- Rex
That might have been true at one point in time but it isn't now. On a stock RHEL5.x you can say 'yum install java-1.6.0-openjdk' and you get a
OK, found it, I'll go known some skulls @ epel.
I'm not sure it's really a bad thing. For example OpenNMS claims it needs b12 or later. But it is curious that apparently no one noticed or knows which is better. Has the history of Linux distro treatment of java (shipping one that doesn't work and being unfriendly to the one that does) completely destroyed any interest?
Many people might not have noticed because they use yum priorities or apt pinning, as they should.
Which one should get priority, and where is the appropriate place to learn that?
by default base+updates should get priority over anything else including epel, don't you agree?
Nicolas Thierry-Mieg wrote:
>> If you have the epel repo installed and enabled during a yum update, you >> get java-1.6.0-openjdk-1.6.0.0-1.0.b12.el5.2 instead of the stock .b09 >> version. Is this intentional and desirable? I thought epel generally >> did not replace stock components with newer versions. > EPEL doesn't replace rhel5 packages, true, and afaict, openjdk isn't in > rhel5. Perhaps a centos addon/extra? > > -- Rex That might have been true at one point in time but it isn't now. On a stock RHEL5.x you can say 'yum install java-1.6.0-openjdk' and you get a
OK, found it, I'll go known some skulls @ epel.
I'm not sure it's really a bad thing. For example OpenNMS claims it needs b12 or later. But it is curious that apparently no one noticed or knows which is better. Has the history of Linux distro treatment of java (shipping one that doesn't work and being unfriendly to the one that does) completely destroyed any interest?
Many people might not have noticed because they use yum priorities or apt pinning, as they should.
Which one should get priority, and where is the appropriate place to learn that?
by default base+updates should get priority over anything else including epel, don't you agree?
Not necessarily. I don't see any inherent reason that I would want openjdk-b09 over b12 and I'd expect the reverse since b12 fixes known bugs. But I would want to know that I'm not the first person to try to run it, which is why I raised the question.
Les Mikesell wrote:
Nicolas Thierry-Mieg wrote:
>>> If you have the epel repo installed and enabled during a yum update, you >>> get java-1.6.0-openjdk-1.6.0.0-1.0.b12.el5.2 instead of the stock .b09 >>> version. Is this intentional and desirable? I thought epel generally >>> did not replace stock components with newer versions. >>> >> EPEL doesn't replace rhel5 packages, true, and afaict, openjdk isn't in >> rhel5. Perhaps a centos addon/extra? >> >> -- Rex >> > That might have been true at one point in time but it isn't now. On a > stock RHEL5.x you can say 'yum install java-1.6.0-openjdk' and you get a > OK, found it, I'll go known some skulls @ epel.
I'm not sure it's really a bad thing. For example OpenNMS claims it needs b12 or later. But it is curious that apparently no one noticed or knows which is better. Has the history of Linux distro treatment of java (shipping one that doesn't work and being unfriendly to the one that does) completely destroyed any interest?
Many people might not have noticed because they use yum priorities or apt pinning, as they should.
Which one should get priority, and where is the appropriate place to learn that?
by default base+updates should get priority over anything else including epel, don't you agree?
Not necessarily. I don't see any inherent reason that I would want openjdk-b09 over b12 and I'd expect the reverse since b12 fixes known bugs. But I would want to know that I'm not the first person to try to run it, which is why I raised the question.
I think priorities set globally should be for base and updates to be highest. In this case there is a particular rpm that the upstream vendor has not yet updated to the later release. Thus those that cannot wait can use yum exclude and thus move to another repo - in this case epel to get a later release. But as always if it breaks you get to keep the pieces..... Works for me.
Rob Kampen wrote:
by default base+updates should get priority over anything else including epel, don't you agree?
Not necessarily. I don't see any inherent reason that I would want openjdk-b09 over b12 and I'd expect the reverse since b12 fixes known bugs. But I would want to know that I'm not the first person to try to run it, which is why I raised the question.
I think priorities set globally should be for base and updates to be highest. In this case there is a particular rpm that the upstream vendor has not yet updated to the later release. Thus those that cannot wait can use yum exclude and thus move to another repo - in this case epel to get a later release. But as always if it breaks you get to keep the pieces..... Works for me.
For some definition of 'works'... How would the person who needed the newer version know it was available if they've excluded it? And since epel isn't 'supposed' to overwrite stock versions (I think Rex verified my impression of that policy), why would you expect to need to exclude epel or lower its priority - or if that does need to be done, why isn't it done in the default *release packages for the repos?
Les Mikesell wrote:
Rob Kampen wrote:
by default base+updates should get priority over anything else including epel, don't you agree?
Not necessarily. I don't see any inherent reason that I would want openjdk-b09 over b12 and I'd expect the reverse since b12 fixes known bugs. But I would want to know that I'm not the first person to try to run it, which is why I raised the question.
I think priorities set globally should be for base and updates to be highest. In this case there is a particular rpm that the upstream vendor has not yet updated to the later release. Thus those that cannot wait can use yum exclude and thus move to another repo - in this case epel to get a later release. But as always if it breaks you get to keep the pieces..... Works for me.
For some definition of 'works'... How would the person who needed the newer version know it was available if they've excluded it? And since
apt-cache policy, yum probably has something similar
as Rob said, having highest priority for base+updates doesn't stop you from installing newer versions from elsewhere if you so decide. It just keeps you from doing so unwittingly.
epel isn't 'supposed' to overwrite stock versions (I think Rex verified my impression of that policy), why would you expect to need to exclude
"supposed" is the key word. only human...
epel or lower its priority - or if that does need to be done, why isn't it done in the default *release packages for the repos?
choosing the priorities for your various repos must be done by the user. Most people probably agree that base+updates should be highest, but beyond that it depends on your needs and personal preferences. In addition having priorities=N settings in the *release packages could be misleading since yum-priorities is not necessarily installed.
Rex Dieter wrote:
OK, found it, I'll go knock some skulls @ epel.
Bug filed, https://bugzilla.redhat.com/show_bug.cgi?id=504189
folks poked, hopefully will see a resolution soonish.
-- Rex
On Fri, Jun 5, 2009 at 2:06 PM, Rex Dieter rdieter@math.unl.edu wrote:
Rex Dieter wrote:
OK, found it, I'll go knock some skulls @ epel.
Bug filed, https://bugzilla.redhat.com/show_bug.cgi?id=504189
folks poked, hopefully will see a resolution soonish.
-- Rex
Still no java browser plugin for Centos? I've been reading the web all night on this, getting angry. I can't find any explanation about why EPEL did have a working browser plugin, but then Centos introduced versions of those same packages that had the plugin removed. Not to mention the fact that Centos keeps the older version (b09) of java-1.6.0, and yet yum seems to think it is a newer version.
So far, the only adequate approach I've found is to install the java-1.6.0-openjdk packages that used to be in EPEL repositories. Every yum update fails after that because yum tries to install the versions from Centos updates, but those updates fail because they don't satisfy the plugin requirement. That's not great because there are some security fixes that come along with the Centos version.
It just seems silly to leave it this way. Are the experts just sick of dealing with each other?
I've been looking at the SRPM files for the competing java-1.6.0-openjdk packages from Centos and EPEL trying to figure how to make a plugin package in the EPEL style but from the java base in Centos.
Well, I'm sorry if these words are too critical. I appreciate the efforts everyone has been making on this.
pj
Still no java browser plugin for Centos? I've been reading the web all night on this, getting angry. I can't find any explanation about why EPEL did have a working browser plugin, but then Centos introduced versions of those same packages that had the plugin removed. Not to mention the fact that Centos keeps the older version (b09) of java-1.6.0, and yet yum seems to think it is a newer version.
Java support is indeed problematic as I pointed out in a recent thread on this list (subject "Recent Java OpenJDK RPMs"). Don't get me wrong, I appreciate that RHEL supports specific certified Java apps, but as soon as one wants to do more (e.g. developing Java apps using recent Eclipse versions, see [1]...), it becomes problematic.
Regarding your issue, currently my approach is to build the latest version locally using the IcedTea build harness: http://icedtea.classpath.org/wiki/RhelBuildInstructions
There is still a problem with the Java plugin on x86_64 though (see [2], not happening on i386) and I build the other plugin using the following configure command (to be adapted with your number of CPUs):
export JAVA_HOME=/usr/lib/jvm/java-1.6.0 ./configure --with-openjdk --with-parallel-jobs=4 --enable-npplugin export JAVA_HOME= make
However see comments #7 and following of [1] for possible problems with this plugin. It works ok for me for what I need (but very slowly).
There was not much reaction on [2]. I strongly suspect that this is an issue with how the x86_64 version of xulrunner is compiled (because of the -fPIC error message). I haven't digged further yet, since the other plugin satisfies my need.
/usr/bin/ld: /usr/lib64/xulrunner-sdk-1.9/sdk/lib/libxpcomglue_s.a(nsThreadUtils.o): relocation R_X86_64_PC32 against `nsIThreadManager::COMTypeInfo<int>::kIID' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status
Anyhow, I definitely need a recent OpenJDK RPM to go in production. That's why I posted the previous thread ("Recent Java OpenJDK RPMs"): I know that this won't be an easy task to do it myself, so I'm first trying to identify similar efforts.
I did not know that there had been an EPEL packaged OpenJdk. Would you be kind enough to point me to the SRPM you found?
I'll keep the list posted on my progress. Comments and ideas more than welcome!
Cheers,
Mathieu
[1] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=401 [2] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=405
Still no java browser plugin for Centos? I've been reading the web all night on this, getting angry. I can't find any explanation about why EPEL did have a working browser plugin, but then Centos introduced versions of those same packages that had the plugin removed. Not to mention the fact that Centos keeps the older version (b09) of java-1.6.0, and yet yum seems to think it is a newer version.
Java support is indeed problematic as I pointed out in a recent thread on this list (subject "Recent Java OpenJDK RPMs").
<snip>
Regarding your issue, currently my approach is to build the latest version locally using the IcedTea build harness: http://icedtea.classpath.org/wiki/RhelBuildInstructions
<snip> I agree with the original poster. Not having the java plugin is fine on servers, but for users here who *do* use it as a desktop, my choices are to either not update openjdk or install Sun's Java, which makes openjdk pointless.
mark
I agree with the original poster. Not having the java plugin is fine on servers, but for users here who *do* use it as a desktop, my choices are to either not update openjdk or install Sun's Java,
Indeed, installing Sun JDK is an alternative. I already tried it with the following procedure:
sudo yum erase *gcj* sudo yum erase *openjdk* sudo sh jdk-6u17-linux-x64-rpm.bin
But then I had to: sudo ln -s /usr/java/default/jre/lib/amd64/libnpjp2.so /usr/lib64/mozilla/plugins/libnpjp2.so in order to get the browser plugin to work (thanks to [1])
Did you face a similar issue? Or did I do something wrong?
which makes openjdk pointless.
Our policy is to use exclusively FLOSS software that we can possibly rebuild, and are free to redistribute etc. Especially for Java which is our main platform. That's the point of OpenJdk for us. Unfortunately, as I put previously, the provided implementation has blocking issues, even on the server/headless side.
I do believe that with Java now GPL, Linux+Java can be a great platform. But there are years of parallel development paths and, if I can put it that way, mutual distrust, that need to be overcome. So it is still a bit painful (but much much better than a few years ago!).
I have the feeling that Red Hat is supporting Java on the long term, e.g. with their ownership of JBoss, and their contributions to OpenJdk/IcedTea (for example the very interesting work of Gary Benson on alternative architectures such as PPC, see [2]).
So I'm very excited to see how Java support will look like on RHEL/CentOS 6...
[1] http://blog.taragana.com/index.php/archive/how-to-install-enable-java-plugin... [2] http://gbenson.net/
On Thu, 31 Dec 2009, Mathieu Baudier wrote:
I do believe that with Java now GPL, Linux+Java can be a great platform. But there are years of parallel development paths and, if I can put it that way, mutual distrust, that need to be overcome. So it is still a bit painful (but much much better than a few years ago!).
A partial Java implementation, mostly GPLv2 -- see the ""CLASSPATH" EXCEPTION TO THE GPL" in the License file; lacking in a FOSS conformance testing suite needed to permit reproduceable testing of the result
It's not there yet; Sun's future is up in the air, and given the pushback on the Innodb (prior Oracle acquisition, left to largely rot since) backend / MySQL 'merger hold' concerns by the EU's anti-trust review organ, it remains to be seen if this will turn out well.
See also this post: http://jeremy.zawodny.com/blog/archives/011481.html by a rather prominent former Yahooian/MySQL maven
Ellison trotting the penguins out on the stage and being tossed a softball question by the then-most prominent MSFT covering analyst at Goldman Sachs, showed him as 'gaming' Linux. Have you seen a lot of good and community oriented support of OEL 2 out there since ORCL started using some un-modified CentOS images in their SRPM rebuild efforts?
my $0.02
-- Russ herrold
Mathieu Baudier wrote:
I do believe that with Java now GPL, Linux+Java can be a great platform. But there are years of parallel development paths and, if I can put it that way, mutual distrust, that need to be overcome. So it is still a bit painful (but much much better than a few years ago!).
I have the feeling that Red Hat is supporting Java on the long term, e.g. with their ownership of JBoss, and their contributions to OpenJdk/IcedTea (for example the very interesting work of Gary Benson on alternative architectures such as PPC, see [2]).
Given that it could have been trivial to include Sun Java ages ago, or at least not intentionally break the jpackage installation methods, I think Red Hat has done more damage to java than any other company and don't see that turning around even if they try at this late date.
Les Mikesell wrote:
Given that it could have been trivial to include Sun Java ages ago, or at least not intentionally break the jpackage installation methods, I think Red Hat has done more damage to java than any other company and don't see that turning around even if they try at this late date.
no, it wasn't trivial due to primarily licensing reasons.
John R Pierce wrote:
Les Mikesell wrote:
Given that it could have been trivial to include Sun Java ages ago, or at least not intentionally break the jpackage installation methods, I think Red Hat has done more damage to java than any other company and don't see that turning around even if they try at this late date.
no, it wasn't trivial due to primarily licensing reasons.
As it turned out, all they had to do to get the license of their choice was to ask. Sun is (was...) responsible for more open source code than anyone. But, Red Hat distributed Netscape back when they didn't like the license. And Debian included Sun Java in the base distribution once redistribution was allowed where Red Hat only put it in the update stream for paid subscribers. And in any case, it would have been trivial to remain compatible with the jpackage nosrc rpms or include them so users could deal with the license requirements without any other hassles.
But the worst damage to java was from distributing a non-standard and mostly non-working version. I doubt if that damage can be undone even if they are actually willing now to distribute something that makes the OS irrelevant and applications portable.
On Thu, Dec 31, 2009 at 8:14 AM, m.roth@5-cent.us wrote:
Still no java browser plugin for Centos? I've been reading the web all night on this, getting angry. I can't find any explanation about why EPEL did have a working browser plugin, but then Centos introduced versions of those same packages that had the plugin removed. Not to mention the fact that Centos keeps the older version (b09) of java-1.6.0, and yet yum seems to think it is a newer version.
I agree with the original poster. Not having the java plugin is fine on servers, but for users here who *do* use it as a desktop, my choices are to either not update openjdk or install Sun's Java, which makes openjdk pointless.
mark
As luck would have it, I have copies of the java-1.6.0 b12 EPEL RPMS that were offered before Centos added java-1.6.0 b09 as an "upgrade" on my home page.
The SRPM is here
http://pj.freefaculty.org/Centos/5/i386/epel-source/packages
And the RPMS EPEL had offered are here
http://pj.freefaculty.org/Centos/5/i386/epel/packages
The RedHat/Centos version b09 is heavily patched for some security things and also to disable the plugin (why??). The Epel version is b12, newer, but not so security patched.
As luck would have it, I have copies of the java-1.6.0 b12 EPEL RPMS that were offered before Centos added java-1.6.0 b09 as an "upgrade" on my home page.
A lot of luck (or foresight...) indeed!
I used these old EPEL SRPMs + my experience of building the OpenJDK on CentOS (see previous mails) in order to adapt the latest Fedora 12 OpenJdk SRPMs (Java 1.6.0 b16, using IcedTea 1.6).
It basically boils down to: - remove visualvm and its netbeans dependency - remove X11 patch - workaround the plugin compilation issue (see previous mails) on x86_64 (the EPEL SRPM was really helpful here)
You can download an SRPM from here: http://www.argeo.org/linux/argeo-el/5/plus/SRPMS/ http://www.argeo.org/linux/argeo-el/5/plus/SRPMS/java-1.6.0-openjdk-1.6.0.0-...
And rebuild it with: rpmbuild --rebuild java-1.6.0-openjdk-1.6.0.0-33.b16.el5.argeo.1.src.rpm (after having properly set up your RPM build environment: http://wiki.centos.org/HowTos/SetupRpmBuildEnvironment)
You need to have the EPEL repo installed.
I could build it and test it on x86_64 but not on i386 (I'm abroad with my x86_64 laptop, and changing the --target did not work, I'll have a look at it when I'm back in the office next week).
I'm currently uploading the x86_64 RPMs but my connection is very bad, so it may take the whole day (or have to wait until next week as well if it fails)
The spec file can be seen here: https://www.argeo.org/svn/dependencies/trunk/org.argeo.dep.rpm/centos/java-1...
As well as the two original spec files I merged: https://www.argeo.org/svn/dependencies/trunk/org.argeo.dep.rpm/centos/java-1... https://www.argeo.org/svn/dependencies/trunk/org.argeo.dep.rpm/centos/java-1...
(you will have to accept our autogenerated SSL certificate)
A few disclaimers/comments: - free software, no warranty, etc. - this upgrades the base java-1.6.0-openjdk package thus you are not in line with upstream anymore if you install it (I am considering to package a version which could be installed in parallel) - this is my first serious SRPM hacking, so comments/critics from more experienced people are welcome! - we are upgrading our infrastructure so the links above are subject to change within the next few months. I'll keep the list posted about what becomes of this (either contributing it to a third party repo, or host it if nobody wants it) - the tests failed and I deactivated hem (just as the EPEL package did at the time). At first sight, it has to do with X11, so maybe part of the X11 patch is needed after all. I'll try to have a look someday (lesser priority though since we don't do much AWT, so help would be welcome here if it is deemed important)
Many thanks again for your help!
Cheers,
Mathieu
On Fri, Jan 1, 2010 at 7:13 AM, Mathieu Baudier mbaudier@argeo.org wrote:
As luck would have it, I have copies of the java-1.6.0 b12 EPEL RPMS that were offered before Centos added java-1.6.0 b09 as an "upgrade" on my home page.
A lot of luck (or foresight...) indeed!
I used these old EPEL SRPMs + my experience of building the OpenJDK on CentOS (see previous mails) in order to adapt the latest Fedora 12 OpenJdk SRPMs (Java 1.6.0 b16, using IcedTea 1.6).
It basically boils down to:
- remove visualvm and its netbeans dependency
- remove X11 patch
- workaround the plugin compilation issue (see previous mails) on
x86_64 (the EPEL SRPM was really helpful here)
You can download an SRPM from here: http://www.argeo.org/linux/argeo-el/5/plus/SRPMS/ http://www.argeo.org/linux/argeo-el/5/plus/SRPMS/java-1.6.0-openjdk-1.6.0.0-...
Hey, thanks. I'm trying it out.
I'm concerned the yum update against the base/updates of Centos will keep trying to install that crappy older version that Centos carries. Have you tested that?
Hey, thanks. I'm trying it out.
There was some issue with the build on x86_64 and I created a new SRPM: http://www.argeo.org/linux/argeo-el/5.4/plus/SRPMS/java-1.6.0-openjdk-1.6.0....
Please test with this one.
Or you can download ready made binaries:
x86_64 (take the one with .2.x86_64 at the end): http://www.argeo.org/linux/argeo-el/5.4/plus/x86_64/
i386: http://www.argeo.org/linux/argeo-el/5.4/plus/i386/
I'm concerned the yum update against the base/updates of Centos will keep trying to install that crappy older version that Centos carries. Have you tested that?
No I have no tested that, neither the i386 to be frank. I will see if I can find time to set up a yum repo today, so that it will make it easier.
If there is interest (please let me know), I am also considering creating a package which will NOT override the existing one.
I have created a YUM repo. Just add a file /etc/yum.repos.d/argeo.repo with the following content:
[argeo-plus] name=Argeo-EL-$releasever - Plus baseurl=http://www.argeo.org/linux/argeo-el/$releasever/plus/$basearch #includepkgs=java-1.6.0-openjdk* gpgcheck=0
[argeo-plus-source] name=Argeo-EL-$releasever - Plus Source baseurl=http://www.argeo.org/linux/argeo-el/$releasever/plus/SRPMS gpgcheck=0 enabled=0
WARNING: I recommend that you use the includepkgs option or the priority plugin, because this repository will contain other packages updating the Base CentOS!! (hence the 'plus' name, just like CentOS Plus)
I'm concerned the yum update against the base/updates of Centos will keep trying to install that crappy older version that Centos carries. Have you tested that?
Actually if you configure the above repo, and just run a yum update you will see that it upgrades the base OpenJdk . (you still need to install the plugin additionally of course).
Installed Packages java-1.6.0-openjdk.x86_64 1:1.6.0.0-1.7.b09.el5 installed java-1.6.0-openjdk-demo.x86_64 1:1.6.0.0-1.7.b09.el5 installed java-1.6.0-openjdk-devel.x86_64 1:1.6.0.0-1.7.b09.el5 installed java-1.6.0-openjdk-javadoc.x86_64 1:1.6.0.0-1.7.b09.el5 installed java-1.6.0-openjdk-src.x86_64 1:1.6.0.0-1.7.b09.el5 installed Available Packages java-1.6.0-openjdk.x86_64 1:1.6.0.0-33.b16.el5.argeo.2 argeo-plus java-1.6.0-openjdk-debuginfo.x86_64 1:1.6.0.0-33.b16.el5.argeo.2 argeo-plus java-1.6.0-openjdk-demo.x86_64 1:1.6.0.0-33.b16.el5.argeo.2 argeo-plus java-1.6.0-openjdk-devel.x86_64 1:1.6.0.0-33.b16.el5.argeo.2 argeo-plus java-1.6.0-openjdk-javadoc.x86_64 1:1.6.0.0-33.b16.el5.argeo.2 argeo-plus java-1.6.0-openjdk-plugin.x86_64 1:1.6.0.0-33.b16.el5.argeo.2 argeo-plus java-1.6.0-openjdk-src.x86_64 1:1.6.0.0-33.b16.el5.argeo.2 argeo-plus
This is because of the -33 instead of the -1.7.
As I said previously, my approach is to track the Fedora version. (that's why we add our build version at the end argeo.1, argeo.2 etc.) With a bit of luck, this should smooth the transition to CentOS 6...
As I said, I have tested nothing on i386 (I just build it), especially not the plugin (which is where most of the differences between the two architectures lie in terms of packaging).
Feedback and ideas welcome!
Rex Dieter wrote:
Les Mikesell wrote:
If you have the epel repo installed and enabled during a yum update, you get java-1.6.0-openjdk-1.6.0.0-1.0.b12.el5.2 instead of the stock .b09 version. Is this intentional and desirable? I thought epel generally did not replace stock components with newer versions.
EPEL doesn't replace rhel5 packages, true, and afaict, openjdk isn't in rhel5. Perhaps a centos addon/extra?
Since 5.3 it is in RHEL 5 (although not the browser plugin). No idea if it only is in the server offering or also in the workstation set.
And it has a lower version number than the one in EPEL.
Ralph
Ralph Angenendt wrote:
Rex Dieter wrote:
Les Mikesell wrote:
If you have the epel repo installed and enabled during a yum update, you get java-1.6.0-openjdk-1.6.0.0-1.0.b12.el5.2 instead of the stock .b09 version. Is this intentional and desirable? I thought epel generally did not replace stock components with newer versions.
EPEL doesn't replace rhel5 packages, true, and afaict, openjdk isn't in rhel5. Perhaps a centos addon/extra?
Since 5.3 it is in RHEL 5 (although not the browser plugin). No idea if it only is in the server offering or also in the workstation set.
And it has a lower version number than the one in EPEL.
It sort-of reflects the old problem of packages being available in third party fedora or pre-fedora repos for ages, then having a different versions of that package appear in the fedora extra or core repos with no coordination with the original packager or repo that introduced it.
-
John R Pierce -
Lanny Marcus -
Les Mikesell -
m.roth＠5-cent.us -
Mathieu Baudier -
Nicolas Thierry-Mieg -
Paul Johnson -
R P Herrold -
Ralph Angenendt -
Rex Dieter -
Rob Kampen -
Scott Silva