On Tue, Feb 7, 2012 at 5:20 AM, Adam Bishop <[email protected]> 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.
