昨天的邮件回复错了,再贴一遍。

我同意xinwei的意见。因为python, perl这类的包数据量太庞大了,所以还是取决于上层软件包的引入,目前2000+的范围还凑合,但是如果再加更多的软件系统进来,这两个的数量就会急剧扩大,所以还是要尽快把上层的应用层的软件补齐,这样牵引我们来引入哪些python, perl等packge,对于其它没有显式rpm依赖的python, perl包,通过pip, cpan就可以了。倒未必非要都打成rpm包。


不过从长远来看,应该有专业的SIG组织来维护和演进这些语言类的package,确实非常专业。gcc, java这块已经有团队进行了看护,其它的语言类型不知道国内是否有比较强的团队能够搞起来。



在 2020-04-17 05:18:18,"Jianmin Wang via Tc" <tc@openeuler.org> 写道:

我也赞同 dillon 的建议,针对 Python(Pypi)、Node.js(npm)、Perl(Cpan)、Ruby(rubygems)、Java(maven等)、PHP(Packageist) 、Rust(Cargo)这类的生态比较成熟、应用非常广泛的可以考虑建立独立的 SIG,建议 TC 或者 Programming-Language 组给一个指导性的原则。

要考虑后续逐渐有更多开源爱好者进来参与时,对于针对 Python、Node.js、Perl、Ruby、Java、PHP、Rust 比较专长的人员怎么快速的能够参与到相关 SIG 组的建立、相关包的扩充等。

另外,xinwei 提到了我理解目前 Linux 发行版的一个目前比较关键的问题是,尤其是目标作为根社区需要考虑的,系统包管理机制与各语言独立包管理机制的关系。

现状是:
1. 这些语言类社区是发行版社区的一个上游社区
2. 每个语言类社区都会有的大量的包,甚至远大于 rpm 包的数量,但软件包的质量参差不齐
3. 发行版社区一般会选择部分包(一般包括运行环境、基础工具、底层包)使用系统包管理格式重新打包来引入
4. 发行版社区集成的包常常版本更新不及时,可能比语言类社区的版本号落后较多

定位分析:
1. 操作系统从定位讲,是整个软件生态的基础,每当发布一个版本后,很强调的一点是稳定,这样整个生态下的软件都能够在一个较稳定的平台上发展。
2. 而对于语言类社区来说,则更为开放,会比较激进的快速更新,快速扩张。比如 npm 已经 120 万了,上面说的这六个除了 Perl ,其他都在 10 万以上的规模,参考链接(http://www.modulecounts.com)。。。 发行版的包数量一般应该还在 10 万以下吧。
3. 另外,不同语言类包的在系统的层级还不太一样, Python、Perl 包括其中基础的软件包已经被系统基础的工具依赖了,是系统必备的。Ruby、Node.js、Java 也有一些包处于这种角色。而 PHP、Rust 相比于系统感觉比较独立一些。

建议:
1. 较大型的语言类应该考虑建立单独的 SIG,尤其是系统依赖较多的,如 Python、Perl、Ruby、Node.js、Java
2. 系统除了包含这些语言的基础运行环境和基础工具外,SIG 组应该针对语言类社区中的软件包做分级,选择核心包、基础包等用 RPM 的方式打包引入
3. 语言类 SIG 组很重要的工作是后期维护,对于 Node.js 这类更新较快的是否跟随上游社区更新可能要慎重选择,首要原则应该是稳定与安全,维护原则应该与其他软件包类似,只不过维护的工作量可能要多一些。
4. 不建议针对用户级的做限制安装在 $HOME,用户应该可以选择安装在系统目录中还是用户目录下,毕竟对于多用户系统来说,在系统目录增加更多的软件来多用户共享使用是常见的需求。只要系统提供了基础环境,至于更多的包如何安装还是由用户自己选择。
5. 长期来说,从操作系统作为一个软件产品角度,对用户来讲还是应该采用统一的包管理优先。

供大家讨论参考。

——王建民


On 16 Apr 2020, at 5:27 PM, Huxinwei via Tc <tc@openeuler.org> wrote:

谢谢dillon的建议。
 
我们最近在梳理sig,语言类的软件以分布在Programming-language为主,各个SIG中在处理各自依赖关系时也会直接引入。
 
我的想法是,当前成功的语言基本上都会有自己的管理体系,比如pythonpipperlcpan
openEuler优先考虑把语言本身的包管理工具以rpm形式整合进来。
这样,原则上系统级(安装到/usr目录下的)由rpm方式管理;用户级(安装到$HOME中)由语言自己的管理。
 
继续演进时,如果有其他rpm形式的软件对语言组件有依赖,则把这些组件根据依赖关系引入。
 
也想听听各位TC委员和同好们的观点。
 
谢谢
 
发件人: dillon.chen--- via Tc [mailto:tc@openeuler.org] 
发送时间: 2020416 17:19
收件人: tc <tc@openeuler.org>
主题: [Tc] [Tc]建议拆分编程语言项目
 
Hi all,
 
    近期对比了一下openEuler和其他linux发行版,个人感觉目前openEuler和其他发行版差距最明显的地方在编程语言方面。而编程语言也是生态的关键,尤其对软件开发者
    建议:
    1. 制定一个规则:什么条件下一门语言可以独立设置一个sig。然后根据这个规则设置一些独立的语言sig比如pythonPHPPerl之类的
    2. 没能独立的编程语言继续放在编程语言sig
    3.语言类项目属于吃力不讨好的类型,如何承接才能做好我就不提了,请大家讨论
 
Regards
陈棋德

_______________________________________________
Tc mailing list -- tc@openeuler.org
To unsubscribe send an email to tc-leave@openeuler.org