SCIENTIFIC-LINUX-USERS Archives

May 2011

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Nico Kadel-Garcia <[log in to unmask]>
Reply To:
Nico Kadel-Garcia <[log in to unmask]>
Date:
Sun, 15 May 2011 10:58:28 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (59 lines)
On Sun, May 15, 2011 at 9:28 AM, Zoran Ovcin <[log in to unmask]> wrote:
> It worked out.
>
> Now I am on Scientific linux, yum update passed ok.

Great. What does "yum list extras" say? And did you re-install all
your packages, so you're not in license violation with Red Hat ?

I'm including below some notes I sent to someone who asked privately
about this a few days ago. A lot of my experience with this is from
CentOS. RHEL 6 got better about various package management, and SL 6's
numbering scheme for repackaged components is very reasonable at
avoiding confusing version skew with RHEL. The policy of replacing
".el6" with ".sl6.0" seems very helpful, as well.

=====================notes==================

That thread was weeks ago! I'm happy for this to be on the list.
Please post, or be willing to let me post, if you're comfortable with
this being public.

The mismatches are subtle. Different GPG keys for the RPM based
packages, subtlely different components for the "sl-release"
components, mismatches of java compatibility modules, and subtle skew
issues with issue.net parsing, by software building tools that need
correction are particular potential flaws. Replacing redhat-release,
for example, with sl-release is tricky. Simply removing redhat-release
removes /etc/issue.net, and this can cause genuine pain if anything
else interesting (such as software building) is in progress. The
sl-release needs to be replaced cleanly, quickly, and early in the
process.

It's especially important to review the components that wind up with
".sl6" in their name. Take guile, for example.the RHEL SRPM is
guile-1.8.7-4.el6.src.rpm. The current SL6 SRPM is....
guile-1.8.7-4.el6.0.sl6.src.rpm. If you've got the RHEL 'guile'
component, you're in good shape. :el6.0: comes after "el6" in RPM
numbering, so you should get the new components. But there's no
guarantee.

CentOS had it much worse, by the way: ".c5" comes before ".el5", and
they weren't willing to gratuitously add the ".0.sl6" that our friends
at SL use. So updates to the new distribution didn't necessarily work.

There is a gotcha if your RHEL was up-to-date and SL has not yet
cauught up with updates: You'll have to run "yum downgrade" commands
to roll back versions to the last SL published version, and that can
get hairy. Also, re-installing *everything* to be sure of getting SL
licenses and binaries and copyrights is.... a lot of work. Some
packages do overwrite config files that you may have edited manually,
and if you've been using "chkconfig --del" instead of "chkconfig off",
daemons might get re-installed automatically enabled. Don't get me
*started* on NetworkManager and people who "just yank the symlinks in
/etc/rc.d!!!"

So, by the time you've done that and run a "yum dowgrade" and then
"yum update" to get the SL version where necessary, and checked for
non-SL packages, you've invested a lot of work.

ATOM RSS1 RSS2