On Tue, Feb 7, 2012 at 5:20 AM, Adam Bishop <[log in to unmask]> wrote:
> That's just what I wanted to hear, thank you.
>
> In the case of depending on something like libuuid, is there an 'ideal' solution, other than mandating a minimum version or maintaining two builds with different version numbers?
>
> I assume the release notes are the correct place to check for breaking changes to packages?
>
> Thanks,
>
> Adam Bishop
In *most* cases, for things like libraries, the built-in dependency
checks of RPM will pretty cleverly detect whether the versions are
compatible. The devil is in the details, though.
Take the example I ran into a few weeks ago: "sssd". I kept a test
system up-to-date using the "6rolling" release, then needed to make it
match a deployed system that was locked down at SL 6.1. "No problem",
says I. "I'll just use the 'yum downgrade'" command for *everything*.
Bwa-ha-ha-ha-ha. No.
Updating "sssd" introduced a version change in its database. When I
rolled back, it broke my LDAP setup, and I had to log in as root to
delete /var/lib/sssd/* before a new database could be generated on the
fly and normal users could log in. If I'd tweaked /etc/ssh/sshd_config
to block remote root access, and didn't have hands&eyes available on
the machine or a remote KVM, I'd have been locked out. Fortunately,
this was a test box, which is why test boxes exist.
Similar problems occur when other databases are updated, such as the
Subverson working copy database. You update Subversion (as occurreed
between SL 5.6 and 5.7 or might occur if you use the Subversion 1.7
SRPM I published), you create new working copies, and you try to
access them with the old version from another machine and you can't
use it with NFS mounts from an old system.
I also had one hell of a time rolling back glibc, due to components
that had been added for new dependencies in 6rolling, such as the
"ipa" tool suite, which had to be deleted before rollback could be
completed. It got..... messy. There are compelling reasons why rolling
back packages to a previous point release, such as between 6.1 and
6.0, is highly discouraged by our favorite upstream vendor, and why
they encourage people to upgrade to the latest point release as a
matter of course before undertaking complex update problems.
This is also why they've done things like separate out new versions of
PHP and Samba into "php26" and "samba3x" packages for years in the 5.x
OS releases. It made the new versions available, but didn't break
working configurations if you wanted to stay with the old releases.
It's also why I get driven *insane* by sites that refuse to upgrade
from locked down old versions of software.
Let's take another excellent and problematic example. My old friend,
"nagios-plugins". It's available from two repositories, EPEL and
RPMforge (now Repoforge). No problem, right? The version numberingi
will keep them separate. and we'll get the most recent version, the
best of both worlds, right?
Bwa-ha-ha-ha-ha. No.
EPEL factors the original nagios-plugins software deployment into
multiple smaller packages, and provides a "nagos-plugins-all" meta
package to get all the default plugins. This allows picking and
choosing plugins and dependencies. Repoforge include all the original
nagois-plugins tarball provided packages in *one* RPM, So when you
EPEL has a more recent version and updates and replaces the Repoforge
version, you *lose* a lot of nagios-plugins and need to replace them
individually or with the 'nagios-pugins-all' package.
Fixing this in the middle of the night because you didn't find all the
widgets that try to auto-update your SL system and the alert system
just went insane is..... not a good thing to have to explain to the
people who monitor your production network. And it's why I *hate* the
multiple auto-update tools installed by default, and prefer the old
"/etc/cron.dadily/rpm" tool that simply reports updates, not installs
them.
|
