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 _______________________________________________ Yum mailing list Yum@xxxxxxxxxxxxxxxxx http://lists.baseurl.org/mailman/listinfo/yum
