二阶段萌新的一些踩坑经验(新人向)

此文章将顺序模拟任务的各个阶段，并给出踩坑经验，希望能为看见的小伙伴们减少一点试错时间。欢迎 OERV 的佬们评论分享出宝贵的经验，给萌新们一个巨人的肩膀(鞠躬

在此页面查看 issue, 确认要认领某一任务时，需要在 oerv 的群里@老师，说明要认领的 issue, 以及自己的 github id。老师同意后，方可进行下一步操作。

升级版本类的任务可以在旧版本的 spec 的基础上修改，因此这里 osc 拉取仓库下旧版本的 package，关于 spec 文件可参考：spec 文件解释

maven 会有自带的 jdk 版本，因此直接在 pom 文件里使用 plugin 标签来指定 jdk 版本没有效果，因为 maven 会优先使用默认的 jdk 版本解决方法：
1. 首先引入高版本的 jdk：
```
BuildRequires:       java-17-openjdk-devel
```
1. 再于 %build 阶段指定 JAVA_HOME
```
%if "%{_arch}" == "riscv64"
export JAVA_HOME=/usr/lib/jvm/java-17-openjdk
%endif
```
关于一个很常见的错误：no such file or directory
1. 此类错误大多发生在 %prep 阶段，多为命名错误和文件位置防止错误，要检查 spec 文件里的压缩包，子模块等命名是否更新。
2. 需要注意的是，有一些包的压缩名称和解压后的名称并不一致，因此需要在 %setup 阶段使用 -n 指定解压后的目录名称: %setup -n <directory name>
一般来说需要修改的文件只有 spec, 以及必要对时打 patch。但是有一些包会使用从仓库里下载的 pom 进行构建，此时需要注意需要同步修改 pom 文件，例如添加新版本的 module 等。

首先需要在 gitee 将中科院邮箱设置为主邮箱。
提前至少两天签署 openEuler 的企业 CLA, 因为有一到两个工作日的审核时间，此处是签署链接，对签署过程有疑问的可以参考此文章，签署后会有确认邮件，注意及时回复。可通过查看自己 gitee 已有的 CLA来确认签署是否已生效。
引入 package 类的 pr 需要在 src-openEuler 下新建一个子仓库来提交相关代码。
升级类的 pr 首先需要评估升级此 pr 后是否会对上游生态产生影响，上游依赖可在 pkgs.org 上查询, 看 Required By 的依赖有哪些，例如：
关于如何向 src-openEuler 提交 pr, 这篇文章有详细的步骤。需要按照步骤操作，这里使用新建分支合并是为了使开发的 feature 变化与 master 分支分隔，建议不要省去，养成好习惯。

积极沟通，群里的佬们都很热情的。一定不要害羞或者害怕露怯，特别是萌新阶段，有时候困扰我们一天的问题可能在群里马上就能解决。但是，要注意提问方式：需要完整的描述自己遇到的问题以及环境，没头没尾的问题只会不必要的消耗提问者和回答者的时间。
对于 java 包来说，可能处理一个包需要引入很多层依赖，这是一个正确的方向，但也需要提前评估大概的工作量，和老师商量确定计划，不能闷着头一直做，避免走弯路。
升级类和引入类的任务主要目的是编写 spec 等文件使 package的源码在 RISC-V 架构上通过编译，丰富 RISC-V 的软件生态。有一些网站例如 fedora 上面会有针对 RISC-V 架构的 RPM 软件包和对应的 SPEC 文件，因此萌新们可以去此类网站上借鉴编译思路，甚至幸运萌新可以在此网站上找到任务的 package。

Provide feedback