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. -------------- next part -------------- A non-text attachment was scrubbed... Name: rkampen.vcf Type: text/x-vcard Size: 121 bytes Desc: not available URL: <http://lists.centos.org/pipermail/centos/attachments/20090604/ac8fe35d/attachment-0005.vcf>