升级后的问题
在智能包管理器里选择全面升级，升级后界面精细了很多，菜单也安排的更合理了，有些疑问1、智能包管理器不见了
2、windows应用程序能直接运行了，会不会受到病毒木马的危害，程序中的打开文件对话框无法使用，这样还有什么意义？
3、the gimp启动后进行操作时就自动关闭了。 千万不要选择全面升级！ 我在想怎么保证源的软件包稳定，可以全面升级 我在想怎么保证源的软件包稳定，可以全面升级
规范 即使规范了也不行。
debian也没办法保证升级不出问题，我就试过。除非你始终只用了仓库。
win程序直接运行应该和病毒木马无关，先不说病毒木马能不能运行（这些东西系统依赖性要强些），即使能运行，也只会影响虚拟的C盘而已。
gimp是因为gcc/gtk版本变动的原因，等我重新编译就好了。 即使规范了也不行。
debian也没办法保证升级不出问题，我就试过。除非你始终只用了仓库。
我觉得 MGC 应该先保证仓库的可升级，只要你安装的是仓库提供的软件，那就基本没有问题。不要管别人有没有自己安装软件，那是别人的事。
如果做不到的话，那大家就不知道什么是可升级的，什么是不可升级的了，仓库就像形同虚设。
可以用一个目录能做为过渡，大家可以添加，但都知道是用于 testing 的，就像 GENTOO 中的 "~x86" 跟 "~amd64" 那样。
事实上，如果仓库可以全面升级那多爽，别的发行版可能都没有做到，但不妨碍 MGC 把这个做为目标吧。
当然，这就要色兄您更辛苦了 ;-) 现在最好的方案就是在升级的时候删除原来的包～～～ 即使规范了也不行。
debian也没办法保证升级不出问题，我就试过。除非你始终只用了仓库。
我觉得 MGC 应该先保证仓库的可升级，只要你安装的是仓库提供的软件，那就基本没有问题。不要管别人有没有自己安装软件，那是别人的事。
如果做不到的话，那大家就不知道什么是可升级的，什么是不可升级的了，仓库就像形同虚设。
可以用一个目录能做为过渡，大家可以添加，但都知道是用于 testing 的，就像 GENTOO 中的 "~x86" 跟 "~amd64" 那样。
事实上，如果仓库可以全面升级那多爽，别的发行版可能都没有做到，但不妨碍 MGC 把这个做为目标吧。
当然，这就要色兄您更辛苦了 ;-)
这个问题我听she兄提及过，主要原因是开发组各成员的开发环境不同导致的。实现仓库的安全升级只有一个办法：净化编译环境，并且在投入仓库前做一次入库检查，以目前松散的开发环境来看，最好的办法是分散开发集中编译。
据KDE兄所述，she兄掌握着最快的编译机器，所以所有的组件在投入仓库前可以提交给she兄重新编译和测试一次，这样就解决了。
据KDE兄所述，she兄掌握着最快的编译机器，所以所有的组件在投入仓库前可以提交给she兄重新编译和测试一次，这样就解决了。
好主意，大家自己打包写spec，然后交spec和源文件就好了，不过色兄就太辛苦了。
据KDE兄所述，she兄掌握着最快的编译机器，所以所有的组件在投入仓库前可以提交给she兄重新编译和测试一次，这样就解决了。
好主意，大家自己打包写spec，然后交spec和源文件就好了，不过色兄就太辛苦了。
好像 FC 有一套软件是用于这个的，在 MGC 3 开始以前，小麦曾让我试着部署一下，但因为能力问题，没有成功。
如果 MGC 有兴趣，我可以再试试
据KDE兄所述，she兄掌握着最快的编译机器，所以所有的组件在投入仓库前可以提交给she兄重新编译和测试一次，这样就解决了。
好主意，大家自己打包写spec，然后交spec和源文件就好了，不过色兄就太辛苦了。
好像 FC 有一套软件是用于这个的，在 MGC 3 开始以前，小麦曾让我试着部署一下，但因为能力问题，没有成功。
如果 MGC 有兴趣，我可以再试试
支持 :D 支持...
据KDE兄所述，she兄掌握着最快的编译机器，所以所有的组件在投入仓库前可以提交给she兄重新编译和测试一次，这样就解决了。
好主意，大家自己打包写spec，然后交spec和源文件就好了，不过色兄就太辛苦了。
好像 FC 有一套软件是用于这个的，在 MGC 3 开始以前，小麦曾让我试着部署一下，但因为能力问题，没有成功。
如果 MGC 有兴趣，我可以再试试
支持 :D
页:
[1]