这太扯淡了.....

cjacker

"由于 Fedora 7 的工具链没有发生重要的改变，一些软件包如果直接从前次发布中继承而没有任何改变的话，将可能保留 ".fc6" 标记。Fedora 维护者决定不再为 Fedora 7 重新编译这些软件包，避免用户不必要的下载。这样做还能避免重新编译可能带来的问题。软件包的命名只是一种表象，不会影响到软件的功能。"

1，这相当于直接在fedora 7中使用fedora 6的二进制。
2，"这样做还能避免重新编译可能带来的问题"，什么问题，编译不能通过，需要修复，又需要时间。


Fedora很好，衍生自fedora的项目很多，从SuSe的一些spec来看，也不排除借鉴fedora的可能。记得以前的SuSe的src.rpm的spec写的很奇怪，基本上没办法直接用的，也就是下载一个SuSe src.rpm，在redhat上打包，要修改spec的很多东西，现在下载一个SuSe的包，除了把Requires和BuildRequires改一下，一般都是可以直接打包的。

但是，Fedora这么搞，也太离谱了，高级服务器版本也会这么搞吗？

dfasdf34fsdf

我的 ACL883 有声了，对我来说就是最大的进步！

狱卒

Post by dfasdf34fsdf
我的 ACL883 有声了，对我来说就是最大的进步！

你的回复跟楼主表达的东西没什么关系吧？

dfasdf34fsdf

至少我看到了进步，也看到了扯淡。

lzliu

Post by cjacker
"由于 Fedora 7 的工具链没有发生重要的改变，一些软件包如果直接从前次发布中继承而没有任何改变的话，将可能保留 ".fc6" 标记。Fedora 维护者决定不再为 Fedora 7 重新编译这些软件包，避免用户不必要的下载。这样做还能避免重新编译可能带来的问题。软件包的命名只是一种表象，不会影响到软件的功能。"

1，这相当于直接在fedora 7中使用fedora 6的二进制。
2，"这样做还能避免重新编译可能带来的问题"，什么问题，编译不能通过，需要修复，又需要时间。


Fedora很好，衍生自fedora的项目很多，从SuSe的一些spec来看，也不排除借鉴fedora的可能。记得以前的SuSe的src.rpm的spec写的很奇怪，基本上没办法直接用的，也就是下载一个SuSe src.rpm，在redhat上打包，要修改spec的很多东西，现在下载一个SuSe的包，除了把Requires和BuildRequires改一下，一般都是可以直接打包的。

但是，Fedora这么搞，也太离谱了，高级服务器版本也会这么搞吗？

其实人家把缘由已经说得很清楚了，也就是说，这些软件根本没有必要重新打包成fc7，内容是一样的，没有必要换一个外壳。放心使用就是了，何必在乎那个名字？

我也用了一些fc6的包，还没有发现兼容性和稳定性问题。

另外，其实RH EL 5也直接用了fc6的包。

wayhomeke

楼上的正解。

skyofdreams

世界上有很多种人，

比如：
A。有一种人在不停的批评，不停的表达不满。但其本意也许本来是好的。
B。 还有一种人在不停的劳做，想做出很好的结果，回报给他人。但是由于各种条件限制，也许结果总是还有不少问题。

显然，A，B的本意都是好的。
但最令人遗憾的是，A指责的人往往是B。

如果我们不考虑本意的话， 应该认识到，最有可能最终解决问题的是B这一类人。

C. 还有一种人，本来是B。但遇到了A，就开始了不断的辩解。成为了这个C类。严重的也会成为A。

这是偶最不喜欢看到的情况之一。
开源的精神是参与、是相互帮助，而不是相互攻击。

在混乱的开源的暗潮中，可能仅有 GNU一直保持着甚至是固执地保持 自由 这个词的阵地。
无论怎样，我觉得，如果一个人是真正热爱开源，那就会慢慢走向B。

dfasdf34fsdf

Computer Science just for You!

cjacker

Post by lzliu
其实人家把缘由已经说得很清楚了，也就是说，这些软件根本没有必要重新打包成fc7，内容是一样的，没有必要换一个外壳。放心使用就是了，何必在乎那个名字？

我也用了一些fc6的包，还没有发现兼容性和稳定性问题。

另外，其实RH EL 5也直接用了fc6的包。

这个说法不太准确，Fedora的打包体系决定了只要这个package rebuild过，就会自动变成fc7，看一下他的spec，里面并不是写死的fc6,fc7，而是编译环境的一个宏定义，也就是rebuild自动生效。

所以，内容是不会一样的，因为只要依赖关系发生变化，编译的二进制就会发生变化，可以简单试一下，自己写个helloworld，两次编译md5值是一样的。

所以，这是偷懒，严重点就是开玩笑。

我说他扯谈是有根据的，这也是RHEL5在某些X86_64机器上频繁崩溃的原因。

还有，fc7的内核默认安装完成后会有一个local_bh_enable的BUG，dmesg可以看到。
这个是因为fc7的一个patch引入的，难道他们就没有测试吗？


绝无攻击的意思，只是指出这些问题。

Fully rebuild是发行版本的基础动作，即使二进制是完全兼容的，但是因为软件包的升级也可能会出现头文件的变化，导致编译出问题，虽然二进制仍然兼容，但是这也是Bug。

而fully rebuild是发现编译broken和二进制兼容必须要做的。

这就是我说扯淡的原因。

hellwolf

既然说道这个问题，我们就来讨论一下软件包兼容性问题。

我们先把软件包分个类，再来结合FC6->F7的升级来看待这个问题。

软件包，我们不妨按照软件类型来这样分类：
1、编译型语言编译的机器代码软件，如C/C++等编译的软件，这在GNU/Linux系统中占据了绝大多数。我们后面也要重点说这种软件的兼容性。
2、解释型语言软件包，如perl/python等。这种软件包，只要解释器没有进行过大的升级动作，就不会产生兼容性问题。如F7的python版本是2.5，FC6最后更新的python是2.4，两版本之间没有引起明显的兼容性问题（这么说可能不精确，希望关注python发展的人指正）。
3、数据软件包。如字体软件，游戏数据包，软件主题、皮肤等数据。这些软件在FC6-F7时，只要不是因为命名方式出现改变，就不会出现兼容性问题。

关于编译型语言编译的软件包，主要是看1、内核／用户态接口的变化 2、库兼容性
关于内核接口，因为都是2。6系列，绝大多数用户态能和内核交互的地方，都基本没有变化，而且， FC6 -> F7 的内核版本是2.6.20 -> 2.6.21。差别当然更小，不足以引起兼容性问题。
接下来就是库的兼容性。
首先是C库
FC6 -> F7 的glibc升级是从2.5 -> 2.6， 看似有0.1的变化，但是和当时FC5->FC6的2.4 -> 2.5不同。 当时FC6的glibc 2.5引入了很重要的.gnu.hash ELF段。 直接导致FC6下打开.gnu.hash编译支持的软件（FC6+的gcc的默认行为）因为glibc的兼容问题根本无法在其他系统上使用（解决办法是附带上FC6+的libc.so.6，并用LD_LIBRARY_PATH覆盖系统libc）。 而这次的2.5 -> 2.6 没有这么激烈的变动。 同样是 libc.so.6，大多软件都不会有兼容性问题。
其次是应用程序库
应用程序需要哪些库？这些在编译的时候就已经确定好，比如：

1. 
   
2. $ldd /usr/bin/vim
   
3.         linux-gate.so.1 =>  (0x00c5f000)
   
4.         libselinux.so.1 => /lib/libselinux.so.1 (0x00284000)
   
5.         libncurses.so.5 => /lib/libncurses.so.5 (0x00a1f000)
   
6.         libacl.so.1 => /lib/libacl.so.1 (0x002de000)
   
7.         libgpm.so.1 => /usr/lib/libgpm.so.1 (0x0029e000)
   
8.         libperl.so => /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libperl.so (0x0034c000)
   
9.         libresolv.so.2 => /lib/libresolv.so.2 (0x002c8000)
   
10.         libutil.so.1 => /lib/libutil.so.1 (0x00322000)
    
11.         libc.so.6 => /lib/libc.so.6 (0x0047d000)
    
12.         libpython2.5.so.1.0 => /usr/lib/libpython2.5.so.1.0 (0x042b9000)
    
13.         libm.so.6 => /lib/libm.so.6 (0x00d40000)
    
14.         libdl.so.2 => /lib/libdl.so.2 (0x00d39000)
    
15.         libtinfo.so.5 => /lib/libtinfo.so.5 (0x00a05000)
    
16.         libpthread.so.0 => /lib/libpthread.so.0 (0x00d6b000)
    
17.         libsepol.so.1 => /lib/libsepol.so.1 (0x00231000)
    
18.         /lib/ld-linux.so.2 (0x00212000)
    
19.         libattr.so.1 => /lib/libattr.so.1 (0x00bba000)
    
20.         libnsl.so.1 => /lib/libnsl.so.1 (0x002ad000)
    
21.         libcrypt.so.1 => /lib/libcrypt.so.1 (0x04289000)
    

复制代码

编译的时候确定好的是依赖libncurses.so.5类似这样的SO名称。我们就以这个libncurses.so.5为例。
哪些时候会出现兼容性问题呢（后面谈yum/RPM系统能解决/避免那些问题）？
1、ncurses升级，改变了API接口而且不再是libncurses.so.5，而变成libncurses.so.6。其结果是导致vim根本无法启动，提示无法定位libncurses.so.5
2、ncurses升级，改变了API接口但仍然为libncurses.so.5。起结果导致的是vim的潜在的不稳定性。这种情况常会发生仍处于开发阶段的软件包——因为开发阶段的包不保证API的稳定性——这也就是使用测试版软件不稳定的最主要原因之一。

好，现在我们看看RPM系统是如何定义vim的依赖关系的：

1. 
   
2. $rpm -qf /usr/bin/vim
   
3. vim-enhanced-7.0.235-1.fc7
   
4. $rpm -q --requires vim-enhanced| grep ncurses
   
5. libncurses.so.5  
   

复制代码

原来vim依赖关系中有明显的一个依赖：libncurses.so.5
这个依赖性是在vim的spec中写的吗？不是，这是rpmbuild系统自动添加的。那谁会提供它呢？再看：

1. 
   
2. $rpm -q --provides ncurses| grep ncurses.so.5
   
3. libncurses.so.5  
   

复制代码

原来ncurses能够提供这libncurses.so.5。这又是谁写的呢？还是rpmbuild系统。

好，这样一来，刚才的兼容性可能中，第一个问题就解决了，因为yum下面，并不允许类似rpm --nodeps, rpm --force这样的不负责任的行为。所以，任何so名称的升级，都会直接导致软件无法安装升级。
第二个问题呢？很抱歉，没有办法解决。改变API接口(包括其行为)而不升级so名称的情况不应该在稳定版本软件中发生。而且请记住一点Fedora的任何正式发型版都是首先考虑稳定版本的。

所以，由此看来，f7中直接_正确地_使用fc6的包的风险相对是非常小的。所谓_正确地_使用，是指通过yum或者一般的无强制模式的rpm命令安装软件包。

至于f7这次没有完全重新编译fc6 extras里过来的包，确实存在很小的风险，但这是在f7是第一次合并core和extras， extras的维护者来自五湖四海，要在短期内完全让这些人跟上发布的脚步，是不现实的。 f7的这次处理就是将fc6中没有broken deps（即没有发生第一个问题的）的还没来得及重新在f7编译的fc6软件包直接拷贝过来。如果你能相信大多数库都能遵循API的接口行为稳定性原则，那你就应该对这次
“草率的”升级有所包容。