Re: What should go in JPP6, and what as update to JPP5? When is support for RHEL versions dropped?
Nico Kadel-Garcia <[email protected]>
| Newsgroups | gmane.linux.jpackage.general |
|---|---|
| Message-ID | <[email protected]> |
On Sun, Jan 10, 2010 at 2:05 AM, Oded Arbel <[email protected]> wrote: > On Sat, 2010-01-09 at 17:11 -0500, Nico Kadel-Garcia wrote: >> I bet you're using CentOS, not RHEL? RedHat's yum setup is basically >> up2date in grandma's clothing. It has no yum config file in which to >> insert repository specific priorities or exclusions, which is really >> flipping irritating. > > I never had any issues setting external YUM repositories on RHEL. It has > been a very very long time since RHEL has used up2date - the setup now > is YUM with a repository config that points to RedHat's secured YUM > repository and a plugin that allows you to access the repository using > the up2date credentials. Obviously its not the fastest setup, but it > uses standard YUM dependency resolution which works well with the > JPackage repo. I'm sorry, perhaps I was unclear. If this isn't too far off topic, it may be helpful to CentOS users debating RHEL use, or vice versa. The yum dependency resolution is fine, in general, but read on. RedHat publishes their yum repository via a non-yum configuration, hidden inside "yum-rhn-plugin". It does not support the use of "protected" or "preferred" yum settings, nor repository specific "exclude" settings, for this particular vendor repository. There's no .repo file to configure. This is why I had to write that "eclipse-ecj" package for RHEL 5, to keep the RHEL package from obsoleting the "ecj" from JPackage and causing endless dependency trouble. The result is *nasty*, if you have preferred repositories with packages that have slightly different naming, such as ".noarch.rpm" versus ".i386.rpm", especially if you install on an x86_64 system. And it's equally nasty if you have locally, preferred stable or modified packages of slightly older vintage than the latest RHEL updates, because it *will* automatically update them to RHEL's packages unless you're very careful and are willing to disable all the RHEL auto-update tools or manually edit yum.conf and block them on an individual package basis for *all* repositories. That's painful. Examples of such problems include ant, for which the ant-1.7.1 from JPackage is installed as a "noarch" package, and "yum update" attempts to install the ant-1.6.5 package in "i386" packaging. Madness ensues.