[FZH] 各位packager,谁有兴趣把libfetion推到rpmfusion nonfree?

Liang Suilong liangsuilong在gmail.com
星期二 三月 30 11:58:59 UTC 2010


2010/3/30 Chen Lei <supercyper在163.com>

>
>
> 在2010-03-30 17:39:59,"Liang Suilong" <liangsuilong在gmail.com> 写道:
>
> 我这里已经有一个能过 koji 的 srpm 了。
>
> 不过我觉得推送到源现在还不太适合,原因有三:
>
> 1. 代码极其不稳定,只要 qt 和 libcurl 更新一下就会崩溃或者登录不上的情况,这不仅仅是在 Fedora
> 上会如此,在其他发行版也会这样,所以放一堆完全不稳定的代码进入仓库对于 packager 而言是很大的工作负担,或者刚进仓库不久就被除名,也不实际。
>
> 这是个关键问题,不过按道理qt curl的ABI是很稳定,不应该出问题才对
>
>
暂时来说是这样,代码我觉得真的不太稳定。


>
> 2. 原来的代码库已经有很久没有更新过了,在 google code 还停留在 svn486,即 1.3 的代码,应该要确定 libfetion
> 是否继续开发,是否已经修复了众多 bug 才提交到 rpmfusion。这个问题我刚刚在 gtalk 问了一下 DongDong Deng,等待回复。
>
>
>  必须确认上游活着才有打包的价值,1.3版能在F13正常运行不?
>
>
这个不太清楚,我得周六日回家才能确定。不过可以肯定的是 x86_64 要比 i686 的稳定性要差些。


> 3. 我一直忧虑如果 linux-fetion 加入 Fedora/RPMFusion 的仓库许可证可能存在问题,因为 RPMFusion
> 虽然容许有非开源程序进入 nonfree,但是貌似进入源之前是要把两者严格地分离开,即是 linux-fetion 的 protocol 和 GUI
> 源码分离开,因为 protocol 是闭源的,而 GUI 源码是 LGPL
> 的,再提交之前我觉得应该是要把两者分离开。而现实两者是十分紧密的,编译也是用同一个 makefile 去编译的。RPMFusion 的 free 和
> nonfree 这两个仓库感觉是完全分离开的。
>
> 这个应该没有问题,N卡的驱动其实也是半开源的,只要作者能授权就行了
>
>
这方面就看你的了,我对 RPMFusion 那边的规则不太熟悉


>  PS:作者提议 libcurl4-gnutls-dev 暂时替代 libcurl4-openssl-dev (以 debian 为例),不过我在
> fedora 找不到前者对用的包。
>
>  libcurl4-gnutls-dev 可以去fedora的bugzilla反应 ,让curl的管理者加上这个subpackage,难度不大
>
>
这个我想也问题不大吧 libcurl4-gnutls-dev 算是 curl 源代码里面的一部分,在 Fedora 直接依赖 curl 就可以了。

>
>
以后记得回复邮件列表的邮件时,直接回复到邮件列表哦,或者 cc 一份也可以。




-- 
Fedora && Debian User, former Ubuntu User
My Page: http://www.liangsuilong.info
Fedora Project Contributor -- Packager && Ambassador
https://fedoraproject.org/wiki/User:Liangsuilong


关于邮件列表 Chinese 的更多信息