来看这篇文章的人，大都应该同意《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-<flavor> 的风格包名，版本号作为 RPM 的属性来实现，但是内核这么重大的包又不能轻易用新的代替旧的，于是再给 yum 新增一个 installonlyn 插件（没错，后面还有个n字母，表示数量）来抑制新的高版本 kernel 代替同名旧 kernel 包的动作。
SUSE系的又如何呢？rpm系不代表是yum系吧
我还没怎么用过SuSE呢
你一定用的CENTOS
CENTOS 的 release 版本号本来就是 redhat-release 的号码，才知道啊～
CentOS 的是 5，而 RHEL 的是 5Server。我就奇怪了，没在哪个配置文件里见到 5Server 这几个字啊……
比对了一下，系统版本的来源的确有些诡异。
看了几次，终于看懂了
re！
今天终于有机会踩到这个坑里了。抬头一看，2009 年……
楼上12年的等等我…14年踩坑的泪目…
你踩啥坑了？
楼上 12年 14年的等等我15年的来了
你们都别慌，16年年底踩坑的来了。
17年年初 踩坑的前来报到。
18年的来了。