我同意xinwei的意见。因为python,
perl这类的包数据量太庞大了，所以还是取决于上层软件包的引入，目前2000+的范围还凑合，但是如果再加更多的软件系统进来，这两个的数量就会急剧扩大，所以还是要尽快把上层的应用层的软件补齐，这样牵引我们来引入哪些python,
perl等packge，对于其它没有显式rpm依赖的python,
perl包，通过pip, cpan就可以了。倒未必非要都打成rpm包。
不过从长远来看，应该有专业的SIG组织来维护和演进这些语言类的package，确实非常专业。gcc,
java这块已经有团队进行了看护，其它的语言类型不知道国内是否有比较强的团队能够搞起来。
我也赞同 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
发行版的一个目前比较关键的问题是，尤其是目标作为根社区需要考虑的，系统包管理机制与各语言独立包管理机制的关系。
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.
长期来说，从操作系统作为一个软件产品角度，对用户来讲还是应该采用统一的包管理优先。
我们最近在梳理sig，语言类的软件以分布在Programming-language为主，各个SIG中在处理各自依赖关系时也会直接引入。
我的想法是，当前成功的语言基本上都会有自己的管理体系，比如python有pip，perl有cpan。
openEuler优先考虑把语言本身的包管理工具以rpm形式整合进来。
这样，原则上系统级（安装到/usr目录下的）由rpm方式管理；用户级（安装到$HOME中）由语言自己的管理。
继续演进时，如果有其他rpm形式的软件对语言组件有依赖，则把这些组件根据依赖关系引入。
近期对比了一下openEuler和其他linux发行版，个人感觉目前openEuler和其他发行版差距最明显的地方在编程语言方面。而编程语言也是生态的关键，尤其对软件开发者
1. 制定一个规则：什么条件下一门语言可以独立设置一个sig。然后根据这个规则设置一些独立的语言sig比如python，PHP，Perl之类的
3.语言类项目属于吃力不讨好的类型，如何承接才能做好我就不提了，请大家讨论
_______________________________________________
Tc mailing list -- tc@openeuler.org
To unsubscribe send an email to tc-leave@openeuler.org