[Yum] yum and indirect downgrades

yum at schlomo.schapiro.org yum at schlomo.schapiro.org
Fri Aug 20 14:39:12 UTC 2010


Hi,

Am 20.08.2010 15:32, schrieb James Antill:
>> The problem we have is that yum seems to realize that it needs to
>> > downgrade the search-server package in order to be able to upgrade the
>> > is24-config-devsol02 package but it only prints out the information and
>> > does not apply the ovious (downgrading search-server).
>  This is intentional ... we only do automatic installs or upgrades,
> not downgrades or removals.
> 
>  Of course you can do it by hand, and with the latest yum you can use
> the new "distro-sync" command (but that will only downgrade if the
> latest version available is older than what you have).
> 

I have seen this, but it did not help.

Some further thought brought me to the understanding that with our
situation yum faces a situation where it cannot make a clear decision
because it does not know that for us the config RPM is the important
one, whose dependencies should be satisfied.

BTW, I tried the same with the smart package manager and behaves a
little bit more as I expect it, downgrading the software RPM in order to
upgrade the config RPM. But on the next upgrade run it would offer to
upgrade the software rpm by downgrading the config RPM to the previous
version that required the higher version of the software RPM. Basically
smart behaved like sitting on a swing, with each run of upgrade it would
reverse the packages.

> [...]
>> > Do you have an idea how to solve this problem? We would like to pin the
>> > releases of search-server in is24-config-devsol02 and be able to take
>> > the release up and down with always running yum upgrade and an updated
>> > is24-config-devsol02 package.
>  If you want to force the version of a package to not change, you can
> use the versionlock plugin.
> 
>  In general I'd say "don't do what you are doing, find some other way"
> but then I'm not entirely sure what you are trying to do and why.

What we are trying to do is manage a server farm through RPMs *only*,
delivering all software and all config files to the server farm through
RPMs which are automatically built from a SVN repository with all the
neccessary information. Each server is personalized through a dedicated
(per host) is24-config-$hostname RPM which contains all config files and
dependencies to the software RPMs that should be installed on the
server. In the end we use RPM dependencies to model our server farm and
have a transactional representation of all our servers and their
functions within the context of RPM.

One problem we have is a "release change" where we would want to be able
to control how a new software release propagates in a wave through all
our servers. One way to do this would be to pin the software version in
the config RPM dependency to the last release and take a smaller group
of the servers and give them the latest software (either by pinning it
in a dependency or by requiring the software RPM without a version and
thus getting the latest version). With this szenario we have only a
small problem, which is that running yum upgrade on these servers
complains about packages which could be updated but run into a
dependency conflict. I would expect yum to figure out that the
dependencies prevent an upgrade as part of selecting all newer packages.

An other problem would be downgrades. Let's say we have a server that
needs to be downgraded to the previous release of the software. The
easiest way in this szenario would be to pin the previous software
version in the dependency within the config RPM (which creates a newer
config RPM) and do yum upgrade is24-config-$hostname on the target host.
I would like yum to interpret this so as to do whatever is neccessary
(up/downgrades) to install the latest version of the
is24-config-$hostname package.

I know that what we try to do here is somewhat new as most admins don't
consider RPM and YUM to be sufficient as a software management tool for
their own stuff. However, I believe that RPM is best at managing the
files on a single computer and that since everything is a file on Linux
we should use the best tool for the job to manage all files on a Linux box.

Of course I am willing to help the tools we use to better support this
use case because I believe that this idea could help a lot of admins to
manage their environment more efficiently.

If you are interested in this topic I will be happy to share some
presentations we created internally to promote this idea.

Kind Regards,
Schlomo


More information about the Yum mailing list