udev extras 的疑問

d00m3d

最近看 UUID，網上很多教程（多是 Ubuntu 的）都教你用 sudo vol_id <device name> 來取得其結果。

回來嚇一跳，怎麼 whereis vol_id 無法找到 vol_id 命令？翻過新舊版 LFS 及 CLFS 手冊，明明說命令是有裝的，奇怪！

再搜索一下及仔細觀察 make install 時的顯示，發現原來 vol_id、scsi_id、usb_id 等 EXTRAS 的命令的確有裝，是裝到 /lib/udev 裡。天~~！於是找台 Debian Lenny 也檢查之，發現同樣也是 /lib/udev 裡。這說明 LFS 的安裝沒有異常，但這也許就說明 Ubuntu 不正常了，/lib/udev 一般不是 $PATH 裡的搜尋路徑，居然可以 sudo？

自己建立連結乎？不解！

RTL

Ubuntu 把 /lib/udev/vol_id 移動到了 /sbin/vol_id
Ubuntu 下的 /lib/udev/vol_id 只是到 /sbin/vol_id的連接


Fedora 8 在 /sbin 下 ln 了個 scsi_id

d00m3d

谢谢 RTL 兄回覆，果然是连结，嘿嘿。

刚查看 udev 包里的官方文档，的确是要求安装到 /lib/udev 去的，Fedora 的做法尚可理解，可是 Ubuntu 本末倒置的做法真的耐人寻味，佩报非常！

聚焦深空

没必要较真，或许可以认为是 ubuntu 易用性思想的一个体现。

对 ubuntu 实在是没好感，debian 都被糟蹋成什么样啦，说实话只有其 livecd 所用的软件列表有唯一参考价值。

udev  新版（好象是从126版开始）开始使用 ./configure，规则默认放在 /usr/lib/udev 下，没有放在 /etc/udev 下，试过各种配置方法均无效，怒，删除继续用老版本。

d00m3d

Post by 聚焦深空;1889317
没必要较真，或许可以认为是 ubuntu 易用性思想的一个体现。

对 ubuntu 实在是没好感，debian 都被糟蹋成什么样啦，[color="Red"]说实话只有其 livecd 所用的软件列表有唯一参考价值。

udev  新版（好象是从126版开始）开始使用 ./configure，规则默认放在 /usr/lib/udev 下，没有放在 /etc/udev 下，试过各种配置方法均无效，怒，删除继续用老版本。

深空兄，指的是 dpkg -l？

想问有哪些地方值得参考的，是它收录某些软件了？

聚焦深空

毁灭兄这么一问，突然发现自己说的有那么点问题。

准确点说，以 LFS/CLFS 作系统的某人，如果自己准备装实现某功能的软件，特别是新版软件，但自己没有相关软件使用经验，又不想一个一个安装试用，此时可以借用 livecd ＋ 虚拟机 试用，以作出最后决定。

ubuntu livecd 可作为 gnome、java 相关软件的试用平台，dpkg -i 也可参考，或许会发现一些有趣的东西。
对 ubuntu 没好感，主要原因是有长期使用 debian 的经历，对比之下高低立现。
suse livecd（可能是opensuse，kde官网有下） 可作为 kde4 试用平台。
redhat livecd（如果有的话） 可作为 glibc-2.8 试用平台。

PS：
有点怀疑 redhat 准备把 glibc 据为己有，连发布都变成 cvs方式的，且没有在 gnu glibc 官网声明，建议大家到 glibc maillist 抗议当前 glibc 维护者的懒惰，在 maillist 中当前维护者说 “建立 tarball 浪费时间，而且 tarball 是过时的”。

d00m3d

RedHat 将软件据为己有早有前科，昔日的 gcc-2.96 便是最佳例证！当年如果不是它，我也不会舍 RedHat 而投 Debian 去，呵呵！

有点怀疑 redhat 准备把 glibc 据为己有，连发布都变成 cvs方式的，且没有在 gnu glibc 官网声明，建议大家到 glibc maillist 抗议当前 glibc 维护者的懒惰，在 maillist 中当前维护者说 “建立 tarball 浪费时间，而且 tarball 是过时的”。

难以想像，建 tarball 都是自动的吧，居然能说出此话，用 cvs 就不过时了？

聚焦深空

http://sourceware.org/ml/libc-alpha/2008-05/msg00074.html
这里有 glibc 当前维护者原话。

其实 cvs 发布也是可以接受的，但不提供 tarball 就有点说不过去，按传统习惯 cvs、snv、git 中的是不稳定版本，而且 cvs 的发布也不利于镜像、校验、安全。

redhat 有自动生成的 tarball
ftp://sources.redhat.com/pub/glibc/snapshots
不过不是稳定版本。

d00m3d

刚把 5 月份的相关 mail archive 及 9 月份的跟进部份全部看完，越看越觉得混账。当前维护者如无心去维护，干脆宣布出来寻找继任人还好，现在不战不和不降，真无奈！

这方面 gcc 就比 glibc 开发及维护的模式强多了！

地球发动机

Post by d00m3d;1891137
刚把 5 月份的相关 mail archive 及 9 月份的跟进部份全部看完，越看越觉得混账。当前维护者如无心去维护，干脆宣布出来寻找继任人还好，现在不战不和不降，真无奈！

这方面 gcc 就比 glibc 开发及维护的模式强多了！

我想是不是该自立门户的时候到了？另外开一个glibc的分支，重点在解决那些遗留的和其他gnu软件不兼容的问题（例如采用奇怪的configparms文件来设置一些重要参数，不支持DESTDIR等等），同时让Glibc能更好融合进GCC里面，简化工具链的构造过程（目标是解压binutils+GCC+Glibc后make一次即生成工具链）。