Linux 存储库管理器如何自我更新的设计原则？
我知道还有其他应用程序，但考虑到 yum/apt-get/aptitude/pacman 是 Linux 发行版的核心包管理器。
今天我在我的 Fedora 13 盒子上看到：
(7/7): yum-3.2.28-4.fc13_3.2.28-5.fc13.noarch.drpm | 42 kB 00:00
我开始想知道这样的包如何自我更新？需要怎样的设计来确保程序能够自我更新？
也许这个问题太笼统了，但我觉得SO比程序员更合适。SE对于这样的问题本质上更具技术性。如果这个问题有更合适的地方，请随时告诉我，我可以关闭，或者主持人可以移动。
谢谢。
I know there are other applications also, but considering yum/apt-get/aptitude/pacman are you core package managers for linux distributions.
Today I saw on my fedora 13 box:
(7/7): yum-3.2.28-4.fc13_3.2.28-5.fc13.noarch.drpm | 42 kB 00:00
And I started to wonder how does such a package update itself? What design is needed to ensure a program can update itself?
Perhaps this question is too general but I felt SO was more appropriate than programmers.SE for such a question being that it is more technical in nature. If there is a more appropriate place for this question feel free to let me know and I can close or a moderator can move.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不知道那些特定的系统是如何工作的，但是......
我想到包管理器还需要将包访问数据库保存在内存中，以确保避免出现竞争条件。同样，chroot 监狱和复制选项可作为风险较低的替代方案。
I've no idea how those particular systems work, but...
It occurs to me that the package-manager needs to hold the package access database in memory as well to insure against a race condition there. Again, the chroot jail and copy option is available as a lower risk alternative.
就像很多事情一样，你不需要专门“设计”来解决这个问题……但你确实需要意识到某些“陷阱”。
例如，Unix 通过引用计数 inode 来提供帮助，因此“您”可以删除仍在使用的文件，这很好。然而，这意味着您必须做一些事情，例如，如果您有插件，那么您需要在运行启动事务之前加载所有插件......即使插件只会在最后运行交易的版本（因为最后可能有不同的版本）。
您还需要执行一些操作来确保您正在更新的任何内容都有效，例如： 在删除旧文件之前先放下新文件。并且不要截断旧文件，只需取消链接即可。但这些也对你有帮助:)。
使用与您通信的外部问题可能会很棘手（因为您无法在更新后执行旧版本的新副本）。但这并不经常发生，当它发生时，它是为了下载之类的事情......这可以在任何更新之前很容易地发生。
还有一些事情在 yum/apt 等 cmd 行客户端中并不需要担心，例如，如果您有一个程序将运行 2 个以上的“更新”，那么如果第一次更新是针对软件包的，那么您可能会遇到问题经理。降级让这变得更加有趣:)。
另外，类似守护进程的进程基本上不应该“加载”包管理器，但与其他陷阱一样......无论如何，出于其他原因，您倾向于遵循这一点。
It's like a lot of things, you don't need to "design" specifically to solve this problem ... but you do need to be aware of certain "gotchas".
For instance Unix helps by reference counting inodes so "you" can delete a file you are still using, and it's fine. However this implies a few things you have to do, for instance if you have plugins then you need to load them all before you run start a transaction ... even if the plugin would only run at the end of the transaction (because you might have a different version at the end).
There are also some things that you need to do to make sure that anything you are updating works, like: Put new files down before removing old files. And don't truncate old files, just unlink. But those also help you :).
Using external problems, which you communicate with, can be tricky (because you can't exec a new copy of the old version after it's been updated). But this isn't often done, and when it is it's for things like downloading ... which can somewhat easily be made to happen before any updates.
There are also things which aren't a concern in the cmd line clients like yum/apt, for instance if you have a program which is going to run 2+ "updates" then you can have problems if the first update was to the package manager. downgrades make this even more fun :).
Also daemon like processes should basically never "load" the package manager, but as with other gotchas ... you tend to want to follow this anyway, for other reasons.