请就软件包管理工具发表您的意见

intact

我早就想过用XML来做。不过实在是太忙了。岁月不饶人哪。

herberteuler

我不希望使用任何复杂的技术。这样会使包管理工具依赖于其他的软件，要使用这个工具就必须同时安装它们。另一方面，不提供依赖问题解决方案的原因是，依赖通常导致冗余软件安装。如果由用户来决定安装哪些软件 (或者说由用户来定义依赖性)，记录依赖性似乎也是多余的：这同时在浪费用户和开发者的时间。事实上，我是由于无法忍受 Gentoo 里删除某些软件时的警告才被迫自己开发管理工具的。我的目标也很简单：一个去除了依赖问题解决方案的 Portage，同时不会对 LFS 的 Keep in mind 有任何的负面影响。

这里顺便问一个问题，和我现在正在试图解决的首要问题，记录软件包里的全部文件有关。我曾经想到过这样几种方案：

1. 用 make 将文件先安装到一个目录下，比如说 /tmp/foo。然后，把这个目录里面的文件全部记录下来。最后，把它们移到实际的位置。这个方案似乎是许多发行版的包管理工具正在使用的，比如 Gentoo，Arch。不过，据说有一些软件包是无法使用这个方案安装的。我实在是不清楚 (因为我刚开始用 LFS)，到底有哪些软件不能使用这种方式安装？比如说，LFS 的启动脚本是不是就属于不能用这种方法的一个例子？

2. 改造 make，使它能够产生文件列表而不是执行命令，或者使它能够在执行命令的同时产生文件列表。不过这种方法有很大的缺点。首先，这会使包管理工具的开发在很大程度上受到 make 的影响。不过最重要的是 make 并不是可以相信的，比如一个 makefile 用一个其他的命令产生了一个文件。

3. 开发一个与 bash 兼容的环境，它具有两种模式。第一种模式是将 / 虚拟到一个普通的目录里，另一种是 / 对应实际的 /。这可以保证对任何的软件包来说都可以记录它们的所有文件，但开发很困难，而且会受到 bash 的影响。

其他的想法似乎都有更大的缺点，所以这里只剩下了这三个。我不认为后两个是好方法，因为如果开发困难的话，引入 Bug 的可能性就会加大许多。不过第 3 个方法似乎是惟一的 “完美” 的解决方法。顺便说一句，LFS 的 Package User 方法我并不太想用。

如果您有更好的方法，或者您对上面的方法有什么建议，真诚地希望您把它们写在这里。我现在实在是太需要它们了。现在的计划最有可能使用第一种方法，因此也希望您能够回答我在上面提出的问题。

herberteuler

Post by 懒猫
希望你能实现这个功能：

假设，我要安装stardict-1.0.0-xxxyyyzzz.xxx，同时附带一大堆可能的依赖包，那么我要搜索并安装“星际译王 1.0”，而不是逐个安装那些用文件名来表示的包

您说的这个特性需要工具具有对解决依赖性问题的支持。这个方面，Debian 的 APT 和 Gentoo 的 Portage 等工具已经解决得很好了。我不准备在我的工具里加入对依赖性问题的解决方案。

地球发动机

也許你需要的是ovlfs，參看
http://ovlfs.sourceforge.net/

qianzheng82

我觉是 slackware 的包管理就很好。楼主是否可以考虑一下？

intact

Post by herberteuler
我不希望使用任何复杂的技术。这样会使包管理工具依赖于其他的软件，要使用这个工具就必须同时安装它们。另一方面，不提供依赖问题解决方案的原因是，依赖通常导致冗余软件安装。如果由用户来决定安装哪些软件 (或者说由用户来定义依赖性)，记录依赖性似乎也是多余的：这同时在浪费用户和开发者的时间。事实上，我是由于无法忍受 Gentoo 里删除某些软件时的警告才被迫自己开发管理工具的。我的目标也很简单：一个去除了依赖问题解决方案的 Portage，同时不会对 LFS 的 Keep in mind 有任何的负面影响。

这里顺便问一个问题，和我现在正在试图解决的首要问题，记录软件包里的全部文件有关。我曾经想到过这样几种方案：

1. 用 make 将文件先安装到一个目录下，比如说 /tmp/foo。然后，把这个目录里面的文件全部记录下来。最后，把它们移到实际的位置。这个方案似乎是许多发行版的包管理工具正在使用的，比如 Gentoo，Arch。不过，据说有一些软件包是无法使用这个方案安装的。我实在是不清楚 (因为我刚开始用 LFS)，到底有哪些软件不能使用这种方式安装？比如说，LFS 的启动脚本是不是就属于不能用这种方法的一个例子？

2. 改造 make，使它能够产生文件列表而不是执行命令，或者使它能够在执行命令的同时产生文件列表。不过这种方法有很大的缺点。首先，这会使包管理工具的开发在很大程度上受到 make 的影响。不过最重要的是 make 并不是可以相信的，比如一个 makefile 用一个其他的命令产生了一个文件。

3. 开发一个与 bash 兼容的环境，它具有两种模式。第一种模式是将 / 虚拟到一个普通的目录里，另一种是 / 对应实际的 /。这可以保证对任何的软件包来说都可以记录它们的所有文件，但开发很困难，而且会受到 bash 的影响。

其他的想法似乎都有更大的缺点，所以这里只剩下了这三个。我不认为后两个是好方法，因为如果开发困难的话，引入 Bug 的可能性就会加大许多。不过第 3 个方法似乎是惟一的 “完美” 的解决方法。顺便说一句，LFS 的 Package User 方法我并不太想用。

如果您有更好的方法，或者您对上面的方法有什么建议，真诚地希望您把它们写在这里。我现在实在是太需要它们了。现在的计划最有可能使用第一种方法，因此也希望您能够回答我在上面提出的问题。

我个人认为像这样处理任意的软件包是不可能的。唯一可以借鉴的就是slak的方式。keep all in head也是不现实的，如果你要维护100台以上的机器，光记录这些就可以占据你全部的时间。所以用Linux就必须会偷懒，不然你学会的只是皮毛。我以前的想法是以不变应万变。就是我上面说的用XML，XML真的是个好东西。你只要想办法去怎么处理你定义的TAG，怎么处理各种情况就可以了。你要考虑到就算同一个软件，也会有很多种不同的安装方式，可以定制安装。这些如果你都是一个一个的去处理，那就丧失了包管理软件的意义。

所以，管理软件包不能局限于软件本身，而应该把这些报看成独立的个体，然后就想写配置文件一样，只要你定义的足够简单，会有很多人帮你来维护。

一家之言，仅供参考。

intact

Post by herberteuler
我不希望使用任何复杂的技术。这样会使包管理工具依赖于其他的软件，要使用这个工具就必须同时安装它们。另一方面，不提供依赖问题解决方案的原因是，依赖通常导致冗余软件安装。如果由用户来决定安装哪些软件 (或者说由用户来定义依赖性)，记录依赖性似乎也是多余的：这同时在浪费用户和开发者的时间。事实上，我是由于无法忍受 Gentoo 里删除某些软件时的警告才被迫自己开发管理工具的。我的目标也很简单：一个去除了依赖问题解决方案的 Portage，同时不会对 LFS 的 Keep in mind 有任何的负面影响。

这里顺便问一个问题，和我现在正在试图解决的首要问题，记录软件包里的全部文件有关。我曾经想到过这样几种方案：

1. 用 make 将文件先安装到一个目录下，比如说 /tmp/foo。然后，把这个目录里面的文件全部记录下来。最后，把它们移到实际的位置。这个方案似乎是许多发行版的包管理工具正在使用的，比如 Gentoo，Arch。不过，据说有一些软件包是无法使用这个方案安装的。我实在是不清楚 (因为我刚开始用 LFS)，到底有哪些软件不能使用这种方式安装？比如说，LFS 的启动脚本是不是就属于不能用这种方法的一个例子？

2. 改造 make，使它能够产生文件列表而不是执行命令，或者使它能够在执行命令的同时产生文件列表。不过这种方法有很大的缺点。首先，这会使包管理工具的开发在很大程度上受到 make 的影响。不过最重要的是 make 并不是可以相信的，比如一个 makefile 用一个其他的命令产生了一个文件。

3. 开发一个与 bash 兼容的环境，它具有两种模式。第一种模式是将 / 虚拟到一个普通的目录里，另一种是 / 对应实际的 /。这可以保证对任何的软件包来说都可以记录它们的所有文件，但开发很困难，而且会受到 bash 的影响。

其他的想法似乎都有更大的缺点，所以这里只剩下了这三个。我不认为后两个是好方法，因为如果开发困难的话，引入 Bug 的可能性就会加大许多。不过第 3 个方法似乎是惟一的 “完美” 的解决方法。顺便说一句，LFS 的 Package User 方法我并不太想用。

如果您有更好的方法，或者您对上面的方法有什么建议，真诚地希望您把它们写在这里。我现在实在是太需要它们了。现在的计划最有可能使用第一种方法，因此也希望您能够回答我在上面提出的问题。

我个人认为像这样处理任意的软件包是不可能的。唯一可以借鉴的就是slak的方式。keep all in head也是不现实的，如果你要维护100台以上的机器，光记录这些就可以占据你全部的时间。所以用Linux就必须会偷懒，不然你学会的只是皮毛。我以前的想法是以不变应万变。就是我上面说的用XML，XML真的是个好东西。你只要想办法去怎么处理你定义的TAG，怎么处理各种情况就可以了。你要考虑到就算同一个软件，也会有很多种不同的安装方式，可以定制安装。这些如果你都是一个一个的去处理，那就丧失了包管理软件的意义。

所以，管理软件包不能局限于软件本身，而应该把这些报看成独立的个体，然后就想写配置文件一样，只要你定义的足够简单，会有很多人帮你来维护。

一家之言，仅供参考。

herberteuler

Post by intact
我个人认为像这样处理任意的软件包是不可能的。唯一可以借鉴的就是slak的方式。keep all in head也是不现实的，如果你要维护100台以上的机器，光记录这些就可以占据你全部的时间。所以用Linux就必须会偷懒，不然你学会的只是皮毛。我以前的想法是以不变应万变。就是我上面说的用XML，XML真的是个好东西。你只要想办法去怎么处理你定义的TAG，怎么处理各种情况就可以了。你要考虑到就算同一个软件，也会有很多种不同的安装方式，可以定制安装。这些如果你都是一个一个的去处理，那就丧失了包管理软件的意义。

所以，管理软件包不能局限于软件本身，而应该把这些报看成独立的个体，然后就想写配置文件一样，只要你定义的足够简单，会有很多人帮你来维护。

一家之言，仅供参考。

谢谢您的意见. 我的初衷就是将 Slackware 的优点和 Gentoo 的优点结合起来, 同时去掉系统对包管理工具的依赖. 至于依赖性问题, 我认为 Slackware 的 KISS 已经很好了.

herberteuler

Post by 地球发动机
也許你需要的是ovlfs，參看
http://ovlfs.sourceforge.net/

非常感谢您提供的链接. 尽管我还没有仔细查看, 但这也许是我最需要的. 不过我无法确定如果我依赖这个的话会有多少软件包因为安装我的包管理工具而被安装. 如果这样的软件包太多的话, 我就不大可能会使用它, 因为这会给 LFS 的简单带来比较大的影响.

herberteuler

Post by 地球发动机
也許你需要的是ovlfs，參看
http://ovlfs.sourceforge.net/

仔细查看以后，我发现这是一个文件系统。我希望我的工具能够运行在许多文件系统上，所以这个还不是我需要的。谢谢您。