我同意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 发行版的一个目前比较关键的问题是，尤其是目标作为根社区需要考虑的，系统包管理机制与各语言独立包管理机制的关系。
现状是：
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. 长期来说，从操作系统作为一个软件产品角度，对用户来讲还是应该采用统一的包管理优先。
供大家讨论参考。
——王建民
谢谢dillon的建议。
我们最近在梳理sig，语言类的软件以分布在Programming-language为主，各个SIG中在处理各自依赖关系时也会直接引入。
我的想法是，当前成功的语言基本上都会有自己的管理体系，比如python有pip，perl有cpan。
openEuler优先考虑把语言本身的包管理工具以rpm形式整合进来。
这样，原则上系统级（安装到/usr目录下的）由rpm方式管理；用户级（安装到$HOME中）由语言自己的管理。
继续演进时，如果有其他rpm形式的软件对语言组件有依赖，则把这些组件根据依赖关系引入。
也想听听各位TC委员和同好们的观点。
谢谢
近期对比了一下openEuler和其他linux发行版，个人感觉目前openEuler和其他发行版差距最明显的地方在编程语言方面。而编程语言也是生态的关键，尤其对软件开发者
1. 制定一个规则：什么条件下一门语言可以独立设置一个sig。然后根据这个规则设置一些独立的语言sig比如python，PHP，Perl之类的
3.语言类项目属于吃力不讨好的类型，如何承接才能做好我就不提了，请大家讨论