NIH syndrome: Yum doesn't work on SuSE 11.1

It seems that yum, a reasonably good, quite standard, and powerful tool for maintaining systems across Redhat/Centos, Fedora, and multiple other distributions … was deprecated in SuSE in favor of an “Invented Here” tool such as zypper.
I am running into this right now with attempting to get OFED installed on OpenSUSE 11.1 to see if this will solve a customer problem. Yum is a convenient and powerful tool, common across many distros. Zypper is not common across many distros.

Moreover, yum can’t be simply dropped in due to python issues. Yum is written in Python, and as people have been discovering, Python 2.4 isn’t quite compatible with Python 2.6++. I can’t let this get by without a little dig here … we have scripts written 15 years ago in Perl that work fine (Perl 4.x), and appear to still work fine in Perl 6 (Rakudo) in compatibility mode.
But I guess yum’s days have been numbered on OpenSUSE for a while.
Changing something that works, that people understand for something new, that we don’t have as much experience with … coupled to SuSE’s long (bad) history with management tool options (SuSE 10.x was a nightmare … you had to force the system to behave as you wanted … often by actively subverting the “helpful” mechanisms).
Lets just say that I am as enthusiastic about zypper as I was in the rest of the previous set of failed experiments in SuSE. I look with great trepidation at trying to help customers adapt to yet another incompatible update method.
I’d like to say “go back to yum”, but this involves other baggage (Python incompatibilities), so it’s not all SuSE’s fault for not using it. I have fortran code I wrote 20+ years ago (eek!) that still compiles and runs correctly. C code from 15 years ago like that. Perl code like the C code. Python? Not so much coding in it. Usually fixing other peoples bugs, but it isn’t my choice of language.
Here’s hoping that yum has crossed the Python 2.6++ barrier so we can force^H^H^H^H^H port yum back to SuSE 11.1 and beyond.

4 thoughts on “NIH syndrome: Yum doesn't work on SuSE 11.1”

  1. Joe,
    1) What is preventing you from having multiple versions of Python on the same machine? I often have 2 versions, both on Linux and on Windows it is quite painless to setup.
    There also might be compatibility pragmas/defines, my memory is foggy on that, I have never needed to used them.
    BTW: Python 3.0 is also said to break backwards compatibility, I have only read about it, I have not tried it yet.
    2) We all have personal preferences and each language/technology had its strengths and weaknesses. I just want to point out that myself, and most of the best software people whom I have had the privilege to work with (at GE, Nuance), have abandoned Perl in favor of Python. At Nuance we had some legacy Perl code, but since about late 2000 it has been all Python. Code readability and maintainability as well as the large, diverse and intellectually deep Python community are the main appeals. And if you like/use math, there are many high-quality Python packages (NumPy, SciPy, bindings for CERN Root/PAW, etc.). Google is also betting on Python (alongside C/C++ and Java).

  2. We use Python extensively, while sticking to Perl in areas where we have a deep code base that it would be difficult to change. Python has a “deprecation” mechanism by which constructs/modules that are scheduled to be replaced by (hopefully) better ones are deprecated for a release cycle (giving deprecation warnings), then removed in the subsequent cycle. I have to say it’s the better scheme. It helps prevent fossilization of the language, as well avoiding the need for the Py developers to maintain multiple simultaneous ways to do more or less the same thing. We have an internal program to change all our own Python codes regularly to keep up. I guess a good question is why Yum does not do the same, assuming this is the issue.

  3. Perhaps the python experts can show how easy it is to get yum running on suse 11.1 w/python 2.6.
    If it isn’t a such an easy task, then maybe python deprecation mechanism should be applied to the language.
    Perl also changes to add new features, but you have to enable them. By default, new features and syntax are disabled, that way old programs will continue working *by default*, with no changes, and it is new-work that bears the onus of adding compatibility flags.
    When non-compatible changes have been made, years advance notice has been given — not the same with python which seems like it’s really in a pre-1.0 development cycle, it’s changing so fast.
    I’m still wary of perl 6.0 — may end up with parallel perls for a while. In the 5.X series, 5.12 is coming up next. I suppose they could just keep incrementing the part after the dot. Say 20 years from now…5.28 – each version having more enable-able features bringing it closer to 6.0 convergence…
    At least you’d have backward compatibility — unlike in python where old source code becomes invalid code.
    It was amusing — you can program python style in perl — but not the other way around — just line up your braces with the code, so when you de-indent, it’s a closure to some previous level of indentation.
    Can’t do perl style in python because python is like permanently wearing training wheels. And then the users go on about how intellectual they are to always have proper coding style due to the enforced style.
    That’s smart? Right….

  4. Perl 6 does look like it fixes some of the things I wanted (switch statements, etc). 5.10 is good, but there is a bug which mucks with Catalyst, unless you apply a patch for the build.
    We are shipping a local build of Perl with our storage/cluster tools. Our experience with the distro-built versions has been non-positive. Redhat is infamous for cherry picking (often bad) patches, including some with significant bugs, or patches that haven’t had much testing and were released for comment.
    So we build our own and stuff works. Which is the way it should be.
    Its interesting that I am getting support requests now for my Sudo module. Will look into it next week.

Comments are closed.