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
imap-utils-2002d-11
pine-4.58-3.SL
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
openafs-debuginfo
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).
L.S.Lowe
Birmingham Particle Physics Group