原帖由 CecilHarvey 于 2010-11-23 09:22 发表 http://www.linuxfans.org/bbs/images/common/back.gif
svn 里面有源代码
不用了，为了一个界面就放弃 mednafen 不值得，何况这个界面我只用了一行指令、一个 mime 类型说明和两个 desktop 文档就合理解决了。
不过真有要请教 CecilHarvey 的，那个我给 mednafen 注册的 mime 对应文件中有 net 后缀的，因为我有一个红白机 rom 有这么个后缀，但不知道是不是错误的后缀，比如有人不小心把 nes 写成了 net。
原帖由 zy_sunshine 于 2010-11-23 09:11 AM 发表 http://www.linuxfans.org/bbs/images/common/back.gif
什么算法？准备做什么？
版本号比较，也就是不光xxx.xxx的，还有字母，日期等等一切都要在一个函数里面提供比较。而且还要支持发行版的修正版本号的支持。
同时还要支持不同大版本的同步开发版本的比较支持。
剩下还有就是包之间的依赖和提供都有版本要求，而且还都不是确定的版本而是大于小于什么的比较版本号，这个需要一个全能的识别功能来识别两个关系是否满足。
噢，这原来也考虑过，但是整体系统会很大，很繁杂。我觉得必须先有人来分模块，写接口文档，提供接口开发参考数据，然后各自开发，最后组合。
我没有考虑发行版间的比较，而是考虑做一个包依赖图结构的显示模块，以直观的形式给开发者提供参考。这主要分两个模块，前台显示和后台依赖分析，首先得按照模拟数据写出前台显示模块，然后再以此为结果分析工具写后台的包算法。
因为现在的发行版包数量都在1500个包以上，如果没有前台显示模块，后台算法分析写起来会很麻烦。
:roll:
前台显示模块和后台算法有要求？前台没事还显示出算法是怎么计算的？
我这个算法要求已经拆的不能再拆了。
原帖由 jiangtao9999 于 2010-11-23 08:36 发表 http://www.linuxfans.org/bbs/images/common/back.gif
没人帮忙想算法，打算放弃了。
算法并不是最重要的，如果都没投入就等于白说，光说不练的话，一辈子都是白话，一直这样的话，就是白话王子了。
实现方法很多都是在多次尝试失败后才总结出来的可行做法，MI2 虽然还不完整，可是的确是这么过来的。
这么说吧，用户根本不关心系统的依赖况状，而系统建设是开发者考虑的，所以要考虑各部件的依赖，而用户所关心的要简单的多，也就是是否符合运行条件而已。
deb 包和 rpm 包的不同可能就在这里， deb 包的依赖是手工提交的，所以它按照打包者的意愿安装，而 rpm 的依赖是系统先行分析的然后手工补充和修正，所以它的依赖是经过反复权衡的。当这两种包放在你面前时，当你希望去分析系统真实的依赖需求时 deb 是不能做为正确参考的，但是 rpm 依赖参考几乎接近百分百，而你只是想安装运行它时， rpm 依赖就成了恶梦，本来就是可以工作的，可是 rpm 体系认为有可能存在某些功用得不到发挥，依赖有可能因为打包者的环境的巨大而变得依赖的无穷无尽。。。如果你没有一些组件的常识，有可能你会被这些依赖所迷惑，因为有些依赖的确是无理的、变态的、过份执着的。
然后我不想继续深入去研究 deb 还是 rpm 的好话差别，因为我想创造的是架设在它们之上的体系：类似于 WinXP 才收进的系统自动恢复记忆功能，并且记忆描述系统因安装或删除发生的变化。
为了系统更好地运行，没人会反对的。
依赖问题用户是最关心的，只不过他们并不知道遇到的很多问题其实依赖问题。一个发行版本身就是以依赖为基础的，发行版的软件包管理器本身设计的目的就是进行依赖管理。
原帖由 jiangtao9999 于 2010-11-24 16:20 发表 http://www.linuxfans.org/bbs/images/common/back.gif
依赖问题用户是最关心的，只不过他们并不知道遇到的很多问题其实依赖问题。一个发行版本身就是以依赖为基础的，发行版的软件包管理器本身设计的目的就是进行依赖管理。 ...
很多依赖并不是需要的，这和你的需求是有关的，当你的系统不需要 odbc 时，你是否希望编译加入大量关于odbc相关的内容？很多组件提供了很广的结口，从 cc++javapython 甚至是 c# (mono) 等等....，提供更多的应用，比如各种数据库的接口。。。odbc mysql pgslq sqlite ....，odbc 又分 iodbc 和unixodbc ...如果用户不需要，那何必强行推销给用户？当然编译涉面广可能学到更多东西，更全面了解这个组件。。。Fedora 这方面非常全，几乎可能用到的全都编译进去并在编译文档中加设开关。当然开关可以让后续者有选择地重新编译组件，但二进制的 rpm 包可就没有办法去开关了。
所以我曾经想换 debian 系的发行版本，但是我发现如果我对系统的了解不够全面，根本就没办法定制系统，因为 rpm 提供了我们再定制绝好的模板，而 debian 你只好去猜去分析去查询了。为什么有群体喜欢 debian，因为可以自由地更换组件，只要足够安全就可以了，而不考虑组件可能要发挥的功能缺失，这些功能有时根本用不到，即便是 rpm体系还要人工干涉分包去除掉。
编译依赖本身就是开发者行为，Fedroa 的 rpm 体系本来就是面向开发的，如果想面向用户，就是尽量简化依赖，无视依赖，依赖只在开发者理解和掌握就可以了。
所以为用户着想就别再搞依赖了，你简单地把自己的系统定义、记录了，把余下的库留给用户去安装，把用户的安装是否安全规范了就可以了。
[ 本帖最后由 haulm 于 2010-11-24 16:57 编辑 ]
我是否可以认为 软件包管理器如果是基于依赖的绝对是一个非常馊的主意，而疲于算法则是庸人自扰。