Linux desktops Scientific Linux 3 differences

Author: L.S.Lowe. File: sl30xdiffs. This update: 20050630. Part of Guide to the Local System.

This file comments on differences between SL3 and RHEL3, and between SL 303 and SL 304 and SL 305 releases. It follows on from my customisation page.

* Extra SL RPMs not in RHEL3

If you do a full install (Everything) with Scientific Linux, then you get some extra SL* RPMs, not part of RHEL, whose scripts have side effects in that they tweak various parts of the system. As they were mostly inappropriate for me, I suppressed them in the kickstart, and implemented one useful one (pagecache) another way. They are:

  SL_afs_no_dynroot   SL_desktop_tweeks   SL_enable_serialconsole   SL_inittab_change   SL_no_colorls   SL_sendmail_accept   SL_startgnome_afs   SL_startkde_afs   SL_tweek_pagecache

I also suppress the following in the kickstart:

  kernel-hugemem   ksh93   GFS   GFS-devel   GFS-modules   GFS-modules-hugemem   GFS-modules-smp

There are also added RPMs in SL, not in RHEL, which are mostly simply useful packages; these include: anacron, cdda2wav, gv, icewm, jpilot, ksh93, openafs, pine, xcdroast, yum. For comments on ksh93, see the customisation page.

Package file clashes in SL30x

In SL30x, the package ksh93 clashes with pdksh over the file /usr/bin/ksh.

In SL304, the package pine clashes with imap-utils over the file /usr/bin/mailutil.

$ rpm -qf /usr/bin/mailutil

Packages in base SL 304 not in base SL 303

For the base packages, there are additional packages in the SL304 system not in SL303; whether these are loaded as part of a particular installation I guess depends on what selection of packages have been chosen to install.

  SL_rpm_show_arch   aspell-config   iscsi-initiator-utils   java-1.4.2-sun-compat   linuxwacom   linuxwacom-devel   mailman   mikmod-devel   net-snmp-libs   perl-BSD-Resource   perl-Compress-Zlib   perl-Crypt-SSLeay   perl-MailTools   perl-Net-Telnet   perl-Parse-RecDescent   perl-Pod-Escapes   perl-Pod-Simple   perl-Proc-ProcessTable   perl-SQL-Statement   perl-TermReadKey   perl-Text-CSV_XS   perl-Text-Template   perl-TimeDate   perl-Tk   perl-Tk-HistEntry   rh-gfs-en   vim-X11

Packages in base SL 303 not in base SL 304


Packages in base SL 305 not in base SL 304

  firefox   j2sdk   jfbterm   openafs-debuginfo   thunderbird

Packages in base SL 304 not in base SL 305

  GFS packages for athlon architecture

Keeping updates up-to-date and SL303 and SL304

Apart from a few additional base packages (above), is a fully-patched SL303 system (using 303 base and errata trees) the same as a fully-patched SL304 system (using 304 base and errata trees)? I see no reason why it couldn't be: Red Hat source updates don't distinguish between different sub-releases. But in practice (as I see it) there is a black-hole in the packages in the errata directory of the SL303 tree: recently updated packages are there in both SL303 and SL304 errata trees, but packages which were updated in the base system for SL304 (like autofs) were not at the same time added to the SL303 errata tree.

So for a system which was installed as a SL303 system but for which you want all SL304 updates, the simple solution is to update /etc/yum.conf so that it uses SL304 as a base and update source, and then run the usual yum update. The sl-release package then gets updated as part of this to show a SL304 system.

If you want the added packages (previous section) then yum install them.

The only remaining package difference is then comps-303 versus comps-304 (which you can remedy if you want to).

Birmingham Particle Physics Group