Node.js 这块我推荐一个 Github 开源仓库 （Star * 2000）的作者，doramart， https://github.com/doramart/DoraCMS 。
他最近刚知道 openEuler 社区，还在看怎么加入。我觉得可以参与到 Node.js 这块 SIG 组的建立。我也抄送上他看是否能够参与进来。
我们基于 openEuler 的版本中针对 node.js 参考上游社区增加了 326 个包 nodejs- 开头的包，这块可以作为 openEuler 扩展 node.js 基础包的参考实现。
Jianmin
On 17 Apr 2020, at 5:03 PM, Huxinwei via Tc tc@openeuler.org wrote:
我整理了下现状，7大之外再加了个go，凑够8仙过海 ;)
Java: 当前80个Maven 软件包，包含maven自身。 Perl: 当前252个语言模块，已经集成了CPAN Python: 当前264个语言模块，已经集成pip (Pypi) Nodejs: 惭愧，openEuler中还是空白 -_-|| PHP: 更加惭愧，天下第一的语言，openEuler中也还是空白 -_-|| Rust: 只集成了rust本身，不过cargo是包含在其中的 Ruby: 当前7个语言模块，已经集成rubygem Golang: 当前19个语言模块，内嵌包管理
各位有没有推荐的大牛？我们可以尝试去接触下的。
Regards Xinwei
From: dillon.chen--- via Tc [mailto:tc@openeuler.org] Sent: Friday, April 17, 2020 4:15 PM To: myeuler myeuler@163.com; Jianmin Wang jianmin@iscas.ac.cn Cc: Huxinwei huxinwei@huawei.com; tc tc@openeuler.org Subject: [Tc] 回复: Re:Re: 答复: [Tc]建议拆分编程语言项目
从Debian，RedHat等Linux发行版的演进历史看也是逐渐演变到独立出这些语言的，社区是否包含这些包和openEuler发行版是否包含这些包是两回事，我的建议是提供这些包但不一定包括在发行版里面 myeuler也是认为长远角度是要建立SIG的。按xinwei的意见，我认为继续演进下去，相信长远也是要建立sig的，xinwei的意见稳妥但是演进会比较慢。一种是逐步演进，一种是现在就独立，长远的来说结果没什么区别。
jianmin意见和我一致，我提这个建议主要是从开发者角度提的，因为发现现有sig绝大多数都是从功能或适用场景来建立的。
折中一下，能否这样，如果jianmin提到的那6种大语言能够建立起专业的团队承接那么就建立SIG？
dillon.chen@turbolinux.com.cn
发件人： myeuler 发送时间： 2020-04-17 15:42 收件人： Jianmin Wang 抄送： Huxinwei; dillon.chen@turbolinux.com.cn; tc@openeuler.org 主题： Re:[Tc] Re: 答复: [Tc]建议拆分编程语言项目 昨天的邮件回复错了，再贴一遍。
我同意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 发行版的一个目前比较关键的问题是，尤其是目标作为根社区需要考虑的，系统包管理机制与各语言独立包管理机制的关系。
现状是：
- 这些语言类社区是发行版社区的一个上游社区
- 每个语言类社区都会有的大量的包，甚至远大于 rpm 包的数量，但软件包的质量参差不齐
- 发行版社区一般会选择部分包（一般包括运行环境、基础工具、底层包）使用系统包管理格式重新打包来引入
- 发行版社区集成的包常常版本更新不及时，可能比语言类社区的版本号落后较多
定位分析：
- 操作系统从定位讲，是整个软件生态的基础，每当发布一个版本后，很强调的一点是稳定，这样整个生态下的软件都能够在一个较稳定的平台上发展。
- 而对于语言类社区来说，则更为开放，会比较激进的快速更新，快速扩张。比如 npm 已经 120 万了，上面说的这六个除了 Perl ，其他都在 10 万以上的规模，参考链接（http://www.modulecounts.com%EF%BC%89%E3%80%82%E3%80%82%E3%80%82 发行版的包数量一般应该还在 10 万以下吧。
- 另外，不同语言类包的在系统的层级还不太一样， Python、Perl 包括其中基础的软件包已经被系统基础的工具依赖了，是系统必备的。Ruby、Node.js、Java 也有一些包处于这种角色。而 PHP、Rust 相比于系统感觉比较独立一些。
建议：
- 较大型的语言类应该考虑建立单独的 SIG，尤其是系统依赖较多的，如 Python、Perl、Ruby、Node.js、Java
- 系统除了包含这些语言的基础运行环境和基础工具外，SIG 组应该针对语言类社区中的软件包做分级，选择核心包、基础包等用RPM 的方式打包引入
- 语言类 SIG 组很重要的工作是后期维护，对于 Node.js 这类更新较快的是否跟随上游社区更新可能要慎重选择，首要原则应该是稳定与安全，维护原则应该与其他软件包类似，只不过维护的工作量可能要多一些。
- 不建议针对用户级的做限制安装在 $HOME，用户应该可以选择安装在系统目录中还是用户目录下，毕竟对于多用户系统来说，在系统目录增加更多的软件来多用户共享使用是常见的需求。只要系统提供了基础环境，至于更多的包如何安装还是由用户自己选择。
- 长期来说，从操作系统作为一个软件产品角度，对用户来讲还是应该采用统一的包管理优先。
供大家讨论参考。
——王建民
On 16 Apr 2020, at 5:27 PM, Huxinwei via Tc tc@openeuler.org wrote:
谢谢dillon的建议。
我们最近在梳理sig，语言类的软件以分布在Programming-language为主，各个SIG中在处理各自依赖关系时也会直接引入。
我的想法是，当前成功的语言基本上都会有自己的管理体系，比如python有pip，perl有cpan。 openEuler优先考虑把语言本身的包管理工具以rpm形式整合进来。 这样，原则上系统级（安装到/usr目录下的）由rpm方式管理；用户级（安装到$HOME中）由语言自己的管理。
继续演进时，如果有其他rpm形式的软件对语言组件有依赖，则把这些组件根据依赖关系引入。
也想听听各位TC委员和同好们的观点。
谢谢
发件人: dillon.chen--- via Tc [mailto:tc@openeuler.org] 发送时间: 2020年4月16日 17:19 收件人: tc tc@openeuler.org 主题: [Tc] [Tc]建议拆分编程语言项目
Hi all,
近期对比了一下openEuler和其他linux发行版，个人感觉目前openEuler和其他发行版差距最明显的地方在编程语言方面。而编程语言也是生态的关键，尤其对软件开发者 建议： 1. 制定一个规则：什么条件下一门语言可以独立设置一个sig。然后根据这个规则设置一些独立的语言sig比如python，PHP，Perl之类的 2. 没能独立的编程语言继续放在编程语言sig中 3.语言类项目属于吃力不讨好的类型，如何承接才能做好我就不提了，请大家讨论Regards 陈棋德 dillon.chen@turbolinux.com.cn _______________________________________________ Tc mailing list -- tc@openeuler.org To unsubscribe send an email to tc-leave@openeuler.org
Tc mailing list -- tc@openeuler.org To unsubscribe send an email to tc-leave@openeuler.org