[Triumf-linux-managers] Re: SL4: Seamonkey instructions

[Kel Raywood]

On Wed, 16 Aug 2006, Konstantin Olchanski wrote:
>I confirm that adding "obsoletes=1" to yum.conf fixes the seamonkey
>stuff-up. I am now investigating why this entry is missing on most
>machines.

yum is not part of RHEL-4 which uses up2date. So it is not surprising that 
SL and CentOS have different yum configurations.

>I am not sure I personally want to sign RPMs provided 3rd parties, even
>SUN. ...

Fair enough.  I only suggested this is a possible way to avoid yum 
failures when upgrading unsigned RPMs.  I too would not be comfortable 
doing it without extensive testing which, as you said, is excessively 
time consuming.

If the unsigned RPMs are in a separate repository, then one other
possibility would be to put "gpgcheck=0" in its .repo file.  But this too
is really no better than self-signing.

I wrote:
>>We use the IBM Java runtime and browser-plugin RPMs on all our machines.

KO responded:
>Good for you, but we have to worry about compatibility wider than "all my
>machines", we have to stay compatible with machines at CERN and other
>labs.

As do we. We are also in the unfortunate position of having to use
software whose source is unavailable to us.  This software has been
certified on RHEL-4 so we, and other PET centres standardise on it. The
policy of CentOS is be 100% binary compatible with RHEL with minimal
modifications and additions (only yum) to the base distribution.  Of
course, there is an optional CentOS-Plus repository and a rebuild of
FedoraExtras for CentOS (http://centos.karan.org/).

Recall that unlike SUN-Java, IBM-Java is built, distributed and signed by
RH for RHEL-4 so in principle, should not introduce any incompatibilities.

>So we are trying to stick to vanilla SL as much as possible.

Is SUN-Java distributed as part of SL?  If so, why don't the SL
maintainers sign the RPMs?

>There is also some mental resistance at running mongrel systems,
>even though we have done it in the past, where absolutely required.

I don't think that adding RH built and signed RPMs to an RHEL
source-rebuild counts as a "mongrel" system.  Adding unsigned SUN-Java
RPMs does count.

>>Up until now it was restricted to java-1.4.2 but in RHEL-4 update 4
>>that was released last week, java-1.5.0 RPMs are available for all
>>platforms (including ppc64).
>
>Yes, but with Java updates, a big worry is application compatibility,
>especially VRVS.

Of course.  That's why the java-1.4.2 rpms are still available.  Note also 
that "1.4.2" is part of the name, not the version number, so they will not 
be automatically updated to java-1.5.0.  It is also possible to have both 
installed.

>... SL4 installs 64-bit browsers on 64-bit machines and common 32-bit
>plugins do not work.

Of course the plugins don't work.  That's why we use the 32-bit browsers.
To do this and have the updates go smoothly, we add (via a custom rpm) an
extra .repo file to /etc/yum.repos.d/ .  It points to the i386 base and
updates repositories (renamed as base.i386, updates.i386) and uses the
"includepkgs" directive to only include the necessary i386 packages (I can 
give you the list if you'd like).

>As we have few 64-bit machines used as personal desktops, it had
>not been a problem, yet.

We only have a few as well, but it's nice to be able to have the browser 
plugins work as they do on 32-bit systems.

--
Kel Raywood
TRIUMF/UBC Positron-Emission Tomography Program