Skip to content

Latest commit

 

History

History
61 lines (53 loc) · 7 KB

2023.1.4-ibheif-罗君.md

File metadata and controls

61 lines (53 loc) · 7 KB

已被PR的包的链接如下

升级各个包遇到的一些问题

  • 问题描述：在升级ibheif 包时候，有一些patch已经被上游合并在最新版本

    • 定位问题 : 无
    • 解决流程：
      • 对照每个patch 查找上游仓仓库对应的PR ，将已经被上游合并的patch删掉
      • 仔细对比最新源代码和打上patch 的版本的区别，判断patch想要解决的问题是否已经被解决

  • 解决流程和方案

    • 定位问题 ： 构建时执行/usr/bin/patch时 返回值不为0
    • 解决流程：
      • 查看spec文件，发现并没有标注patch是否有对应上游的issue问题
      • 对比上游 1.9.15p5 版本和 1.9.14p1 版本，发现对应patch里面的内容并没有被上游的仓库更新
      • 百度查询 git 打patch 的方法，找到了git如何给不同版本打patch【非常便利】
      • 对照着原来的patch修改源代码，然后使用git format-patch 打patch，替换原来的patch
      • 重新构建

  • 问题描述：在升级sudo 包到版本1.9.15p5时候，发现版本src-openeuler仓库和上游github中sudo源码仓库的代码差异较大，同时当时使用打patch的社区伙伴并没有向上游提交,在最新版本构建的时候会报错 在执行 patch命令的时候返回值不为0

  • 解决流程和方案

    • 定位问题 ： 构建时执行/usr/bin/patch时 返回值不为0
    • 解决流程：
      • 查看spec文件，发现并没有标注patch是否有对应上游的issue问题
      • 对比上游 1.9.15p5 版本和 1.9.14p1 版本，发现对应patch里面的内容并没有被上游的仓库更新
      • 百度查询 git 打patch 的方法，找到了git如何给不同版本打patch【非常便利】
      • 对照着原来的patch修改源代码，然后使用git format-patch 打patch，替换原来的patch
      • 重新构建

  • 一些修包的想法

    • 在升级版本差异较大的包的过程中，最好先查看上游github仓库里面官方给出的如何构建的流程，【需要啥构建依赖，需要啥运行依赖，以及怎么配置，怎么构建】，能把spec 文件更新一下最好（OS： 我看sudo github官网给的所需要的依赖不是那么多，构建流程也不麻烦，就./configure 选择选项配置，然后在make build 就好，但是spec里面的流程操作给的比较麻烦，我尝试删了一些依赖，然后重新写构建流程，然后就荣获一堆ERROR，最后还是改回去了）
    • 还是尽量多看看SPEC文件怎么写啦【这个对修包还是很有帮助】
    • 看到里的UU们，可以自己去社区找一些ISSUE来做，可以找自己比较熟悉的软件来做，这样工作效率会高一些，产出率也会高一些【并不是说要待在舒适圈（，就是单纯的完全不清楚一些环境依赖的话，可能还得自己先学很长一段时间的相关环境和管理工具 比如JAVA 里面常用到的MAVEN之类的】

工作流的思考与分析

  • 首先是对pre-task里面的qemu-user + nspawn 启动容器的思考 【如有错误，麻烦佬们改正啦】
    • 问题一 ： 我通过qemu-user + nspawn 的方式在riscv64 的环境下构建会对本机环境造成破坏吗？
      • 不会，上述方式构建的本质是 在 /var/tmp/buildroot 启动一个特殊的文件系统 ，同时开启一个服务 binfmt ，这个服务可以让内核把他认识的ELF格式【认识的ELF格式应该会在PRE-TASK3 里面注册到不知道哪里去【本质可能是增加对ELF头部元数据的识别】】的文件传递给应用程序，然后使用nspawn在 /var/tmp/buildroot 下启动对应的容器，这个容器就是一个具有完整文件系统的RISCV-OPENEULER 可以在/var/tmp/buildroot/的子目录下面找到bin 使用file 查看发现是 RISCV64的ELF文件，然后通过binfmt 服务 将对应要执行的ELF文件传递给qemu-user-riscv64 ，这样就构建好了环境，简单理解来说就是所有的软件环境，都只会安装在 /var/tmp/buildroot 下面，不会对本机做任何的不良的影响
    • 问题二 : 通过qemu-user + nspawn的方式构建好了包之后 ，能通过他来验证运行时的使用吗？
      • 目前我还没有找到方法，按照道理来说可以， 以 /var/tmp/buildroot/ 下面的目录作为容器的根文件系统，然后启动RISCV64的容器，安装RPM包之类的， 目前是还是通过qemu-system-riscv64启动 openEuler 23.09 然后本机开启一个http文件服务器，在模拟器里面使用 wget 把RPM包下载下来以验证运行时是否正常
    • 问题三 ： SPEC里面的依赖从何而来，应该怎么写？
      • SPEC里面的依赖有构建依赖和运行依赖，我们可能更加关注构建依赖
        • 每次RPMBUILD工具分析一个SPEC文件的时候，会分析他的头部的META数据，发现有这么一些依赖，然后会从自己管理的RPM包列表里面搜索，查找是否存在这个依赖包，检查对应版本，如果正确就下载下来，否则给予报错
        • 那RPM包列表里的RPM包从哪里来，以下是个人分析：可能是从配置好的REPO源来，从REPO源里找对应的名字的RPM包
        • 所以可以对发行版有一个更深刻的认识了，不同发行版很重要的是他的源，如果随便换源，会导致很多软件崩溃，因为如果你是ubuntu, 那么对应的有ubuntu 软件包的源，你的所有的包，都应该是ubuntu 维护更新的，如果随意换了一个源，可能以前在ubuntu安装的软件都是从ubuntu源下载的rpm包，他们可能在RPM里面有自己的名字（这里不知道是不是？）：） ， 在新的源里面的名字，版本都不一样，解析你的SPEC的运行依赖或者构建依赖时又去下载了一些新的源的RPM包，然后应该会G

一些可以参考的方法和文档

  • RPM SPEC 比较全的文档 https://rpm-packaging-guide.github.io/#what-is-a-spec-file
  • 升级包时，如何对待patch
    • 在上游存在issue的patch
      • 查找上游是否已经close 对应的issue
      • 查找提出issue的人在相关仓库的PR
      • 对比需要更新的版本和当前的包的版本，查看patch里面的内容是否合并
      • 如果在上述三条里面查询到了对应的记录，直接删除patch就好
      • 如果没有，注意仔细对比patch 打补丁的文件是否在新版本代码里面是否改动，【因为diff的原理是对某一行进行删除，或者改动嘛，如果在新版本里面有改动，对应的需要patch的地方行数可能会有变动】，然后及时重新打patch
    • 在上游不存在issue的patch
      • 注意仔细对比patch 打补丁的文件是否在新版本代码里面是否改动，【因为diff的原理是对某一行进行删除，或者改动嘛，如果在新版本里面有改动，对应的需要patch的地方行数可能会有变动】，然后及时重新打patch
  • 修包时，该以什么角度来考虑
    • 参考工作流的思考与分析