yum 变量

http://www.opstool.com/article/294

新机器使用yum出现了报错,发现本来应该替换的$releasever变量变成了%24releasever

http://mirrors.aliyun.com/centos/%24releasever/addons/x86_64/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found

Trying other mirror.

Error: Cannot retrieve repository metadata (repomd.xml) for repository: addons. Please verify its path and try again

下面我们来看看这个是怎么回事，最好的参考文档当然是man，通过man yum.conf 查看这个$releasever

$releasever This will be replaced with the value of the version of the package listed in distroverpkg. This defaults to the ver-

sion of ‘redhat-release’ package.

$arch This will be replaced with your architecture as listed by os.uname()[4] in Python.

basearchThiswillbereplacedwithyourbasearchitectureinyum.Forexample,ifyourbasearch This will be replaced with your base architecture in yum. For example, if your arch is i686 your $basearch will be

i386.

YUM0−YUM0-YUM9 These will be replaced with the value of the shell environment variable of the same name. If the shell environment

variable does not exist then the configuration file variable will not be replaced.

可以看到 yum中有这几个变量: releaserver、releaserver、arch、basearch和用户自定义的basearch和用户自定义的YUM0-$YUM9。

有一个简单的python命令可以看到yum的 releaserver、arch、basearch的值

/usr/bin/python -c ‘import yum, pprint; yb = yum.YumBase(); pprint.pprint(yb.conf.yumvar, width=1)’

对于Yum正常的机器，releaserver变量都有定义

{‘arch’: ‘ia32e’,

‘basearch’: ‘x86_64’,

‘releasever’: ‘5’}

而对于今天Yum有问题的机器，releasever没有定义

{‘arch’: ‘ia32e’,

‘basearch’: ‘x86_64’,

‘releasever’: ‘releasever’}
变量releasever’}
变量releasever 的值来自 distroverpkg ，下面我们找一下 distroverpkg是怎么来的，还是在man yum.conf手册中。

distroverpkg The package used by yum to determine the “version” of the distribution. This can be any installed package. Default

is ‘redhat-release’. You can see what provides this manually by using: “yum whatprovides redhat-release”.

distroverpkg 定义了一个包名，通过这个包命，执行yum whatprovides $distroverpkg yum就知道了系统的发行版本。

这里默认的值是redhat-release。

对于正常的CentOS系统。执行yum whatprovides redhat-release 可以看到结果

10:centos-release-5-10.el5.centos.x86_64 : CentOS release file

Repo : base

Matched from:

Other : redhat-release

10:centos-release-5-10.el5.centos.x86_64 : CentOS release file

Repo : installed

Matched from:

Other : Provides-match: redhat-release

而对于今天遇到的yum有问题的机器，执行这个命令则没有结果。

http://julyclyde.org/?p=275

来看这篇文章的人，大都应该同意《Unix编程艺术》中提到的那些观点吧。今天就给大家看一个反例：yum 的 $releasever 变量

在 /etc/yum.repos.d/ 目录下的软件库定义文件中，常常会在 baseurl 的路径中提到 $releasever 这个变量，表示当前发行版的大版本号，但大家知道这个变量是在哪设置的吗？我 grep 了整个 etc 目录都没找到，还是看了 yum.conf 才知道的，是在 yum.conf 文件里 distroverpkg 选项定义的。但这个选项就很有问题：

distroverpkg 和 releasever 名字不同，且看不出什么联系

distroverpkg 的值，并不是明文，而是“redhat-release”。不知道大家看到这个会有什么想法，反正我是首先想到了 /etc/redhat-release 文件，但我错了。实际上指的是 redhat-release 这个RPM包。所谓“distroverpkg=redhat-release”的意思，其实是将 $releasever 设置为 redhat-release 这个RPM包的版本号

够变态吧？别人都是直接赋值，或者 include 一个各种变量定义的文件进来，而yum竟然用某个包的属性作为值，违反了“everything is file”的原则。烂！用属性实现，则相关软件必须能读取属性。这个功能对于yum来说无所谓，但是对于别的软件呢？还得特地加入rpm相关的代码才能实现，加入了平台相关特性，降低了可移植性，麻烦。正确的方法是以文件内容作为表示形式。当然了，这样的话用属性就没意义了，yum还能减点肥。

另外，如果/etc/redhat-release 文件和 redhat-release 包标示的信息不同，又该以哪个为准呢？redhat犯过不止一次这样的错误了，比如ifcfg-eth0里可以写DEVICE=eth1之类的。一个信息到处存放，则必将面临各处副本不一致的危险。

有人为心爱的 RedHat 分辩说是为了升级 redhat-release 包之后可以自动升级整个系统，但事实证明 RedHat 的选择一向都是很傻的。为什么不在软件库定义文件中 include 一个表示版本号的头文件，每次大升级的时候更改这个文件呢？

再举个例子：

Debian系里面，内核包的版本维护是利用一个虚拟的某个风格的内核包，比如 linux-image-generic 包，而该包又依赖于 linux-image-2.6.28-15-generic，后者就是真正的内核包，其版本号直接写在包名里，同时也表现在包属性里。系统升级的时候，由于 linux-image 和 linux-image-generic 的依赖关系变动，会依赖于新的 linux-image-2.6.xx-yy-generic 包，自然会装上。而新的 linux-image-2.6.xx-yy-generic 和旧的根本不是一个名字，因此旧的内核包不会“被升级”掉。apt后加入的删除无用包的功能可以指定不删除 linux-image 开头的所有包。

反观 RedHat系 的做法：各个内核包，只有若干个 kernel- 的风格包名，版本号作为 RPM 的属性来实现，但是内核这么重大的包又不能轻易用新的代替旧的，于是再给 yum 新增一个 installonlyn 插件（没错，后面还有个n字母，表示数量）来抑制新的高版本 kernel 代替同名旧 kernel 包的动作。