谈谈二进制包发布和软件管理器

zy_sunshine

关于包管理器这东西cn是一定要出一个，但是不知道谁去做，管它呢。

如果能把软件打包变得更简单，ML可能会具有一定优势。

看了以前的讨论贴有所感悟，想发表一下自己的意见：

1、包管理器无须重新发明。
2、http://autopackage.org/ Stable release: 1.4.2  Posted by Jan Niklas @ May 24, 2009 似乎不错，有空试试。
3、关于软件包安装方式的设想：（简单的如同Win安装卸载管理器）
这里设想的安装卸载方式是针对应用软件包的，应用软件包不包括Magic发布的系统软件包。想卸载系统软件（例如，网络管理器）没门，你只能去用命令行或者smart

应用软件包的打包方式：
打包者（爱好者或写软件的人）将编译好的二进制程序打包（随便什么二进制包都可以，只要能自动释放就行），再附加一个依赖库描述文件。就这些。
关于依赖的库和软件，以统一接口描述。具体表现为所需库或软件的名称和版本范围。其实这个就是一个依赖的描述文件。
Magic管理组件分析该依赖描述文件，并检查系统是否具有相关依赖，如果缺少相关依赖就去Magic库中下载并自动安装（此处可以直接调用rpm或者smart）。
到此，我们完成了二进制软件包的依赖库问题。至于二进制软件是否可以运行，那就看造化了。

这里又出现了几个问题：
1、rpm，bin，run（run好像不全是二进制形式）等二进制包可能不适合Magic版本，那我们在前面已经解决了他的share库依赖问题，那能运行的可能性就很大了，因为我们所用的编译器、计算机hierarchy都是i686、库版本等都是一样的。而且我们遵守Filesystem Hierarchy Standard。
2、打包者针对MagicLinux上的一些库依赖描述是否会很麻烦，如rpm描述一样？这是不会的，我们可以提供一个GUI前台，只要从一个库列表中选择相应的库就行了。这个库列表可以直接分析Magic库中包文件生成。

优势：
1、所有二进制包都可以用于Magic，只要简单的从列表中指定依赖库就ok
2、我们只要把精力放在各种库的打包就可以，其他应用软件打包者可以很容易的给出。
3、需要指明的是 普通系统使用者在使用软件的时候是不会去关注软件的源码的，他们需要的只是二进制包，下来源码进行编译也就是为了获得二进制文件吧？
     软件打包者最烦的是库依赖问题。
     我设想的这个东西就是为了直接解决二进制包的库依赖问题，所需的就只是一个依赖列表。

当然细节上可以更人性化，例如：
先检查系统中是否已经安装了相同名称的软件，采取具体的措施。
包命名格式要有一定版本规范以区别时间先后。
分析二进制包安装命令--help 可以指定安装位置，如果不是标准的--prefix就不管他了，谁让他不标准的。

另，rpm打包可以给个GUI前台，方便任何人将其他几个主流平台的rpm包转换magic形式，或者干脆搞个包自动转换器，关于这方面我的经验比较少，也就是想想。

zy_sunshine

一句话：
目的，自动解决解决二进制程序依赖库问题

haulm

以前我的观点是所有的组件最好在本系统上重新编译，不过现在Linux组件对类库的兼容都有所改善。不大可能说用magic的包管理器去转换别人的安装包，这个思路肯定走不通。
国内没有什么Linux软件的开发，所以统一的安装管理口径也难以实现。
所以Linux也需要类似win一样的注册表，而且提供注册表还要得到软件包制做的认可才行。
win的添加删除管理也并不是很尽责的，一些绿色安装包和病毒、广告、木马都不会在里面留下东西。
考虑给magic添加注册表项也能实现一部份，比如手工写一些脚本分析系统然后写进注册表里，再后面软件开发者才会考虑自己添加什么。
这个mgc实现太难了，如果ubuntu或fedroa肯实现就容易多了。

haulm

我又想起jagen谈到的auto magic build system，简称mbs，如果这个实现了，重编译一次系统就只要一个指令了，那么我们重新生成一个注册表也是一个指令了。
再把一些常用软件的特征编辑造册，一般它们都有提供man或者别的什么的，然后也就可以分析补充了。
最后提供方便的打包界面程序，共享软件的开发安装就有默认的GUI界面了。
其实Win就是这么过来的。

zy_sunshine

我的设想就只是解决软件运行的库依赖问题，至于这些软件能不能运行那就不保证了。

最后一个观点，做rpm转换器，那就是说说。针对几个主流linux发行版本还是有点可能的。

坚持将Magic发展为独立的Linux操作系统。

zy_sunshine

alfs？Linux底层库一变，参数就要调节，维护这个mbs应该非常难。

jiangtao9999

软件包依赖库不是问题，直接做成 rpm 就可以完全达到楼主的要求，而且如果这个软件只做成一个 rpm ，那么卸载也是很方便的。
现在软件主要问题是，安装容易卸载/升级难，因为你把这个程序软件包卸载了，但他依赖的软件库并不一定绝对需要了，这样的话，同时卸载不需要的依赖包才是二进制包发布程序所需要解决的问题。

总的来说，只要有一个足够全面的软件数据库，以及一个足够用的算法，这应该不是问题。
现在主要是 rpm 还需要自己编写 spec 。其实 rpm 本身已经自带导出依赖库的功能了。 他可以自动查找这个软件依赖的所有 so ，之后放入 dep 列表里面，不过没有软件包的名字，只有 so 文件的名字，所以这里依然需要一个足够全的软件包数据库的支持。

jiangtao9999

其实写一个 rpm 包生成器就行了，这个其实很多的，如果能生成 spec 、可以自动生成 src.rpm 和二进制 rpm 的图形化程序我想更好了。

zy_sunshine

第一点，直接做成rpm的包应该可以，但是我想要非rpm的bin包也可以用于Magic上。给这些所有bin包一个接口描述依赖关系。只要这些bin包可以自动安装到相关目录就行。（好像bin包也就.bin这一种）

第二点，只要再rpm的基础上附加一个包锁定机制就可以了，我想这个smart上应该都有了吧，在二进制包卸载后，对该软件的相关依赖做个检查就行了，如果是该软件的依赖，同时又不属于其他包的依赖就可以卸载。

第三点导出软件所依赖的库是否用的ldd命令？获得依赖库的文件名再由一个数据库做包名转换这块有没有人已经实现了？

我对spec不熟悉，只是了解，没有实际用过。

大家都谈谈，只要有了正确的观点，那么做这些东西才有意义，如果方向都错了，那也没有必要去做这些。

zy_sunshine

rpm 包生成器有前车之鉴吗？

我的观点是，能自动化处理的重复性操作全部给计算机去做。给软件使用者的用的都是超级简单的功能接口，就算是白痴也会的那种。

jiangtao9999

第一点：那不还是重写 bin 才行么？这和直接改为 rpm 包又有什么区别？现在的 bin 包就是一个可以运行的程序，运行他就会把数据解压缩的系统里面，他本身如果要进行什么依赖的操作，都要去操作 rpm ，当然你这个想法可以让这个 bin 同时支持多种软件包管理器，比如 deb ，但这种操作，感觉还不如直接写成 rpm 、 deb 等等的包来的快捷。

第二点：这个可以实现，但数据库必须够全，有些软件包管理器已经有这个功能了。

第三点：好像 rpmbuild 生成包时就有这个功能。不过我没有研究……