forked from openkylin/docs
新增openKylin源码自主选型构建流程
This commit is contained in:
luoyaoming
parent
b96f7fec64
commit
89c5a70e71
|
|
@ -0,0 +1,651 @@
|
||||||
|
# openKylin源码自主选型构建流程
|
||||||
|
|
||||||
|
# 一、软件包版本号选型
|
||||||
|
|
||||||
|
## 1. 选型策略
|
||||||
|
|
||||||
|
### 1.1 软件项目选型策略
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
- 持续积极引入全“A”软件(版本)
|
||||||
|
|
||||||
|
- 鼓励引入仅含”A"和”B”软件(版本)tory-view-113483.html
|
||||||
|
|
||||||
|
- 谨慎引入含"C“软件(版本)
|
||||||
|
|
||||||
|
- 拒绝引入/及时删除含“D”或者“C >= 3”的软件(版本)
|
||||||
|
|
||||||
|
### 1.2 软件版本选型策略
|
||||||
|
|
||||||
|
- 长期支持版本(暂时openKylin还没定长期支持版本，1.0目前来说不是长期支持版)
|
||||||
|
- 兼顾质量与稳定，优先选择主流OS广泛应用的版本。
|
||||||
|
- 升级后不影响兼容性列表。
|
||||||
|
- 同一个版本生命周期内不做大版本变动，仅采取特性、补丁回合的方式解决质量问题。
|
||||||
|
|
||||||
|
- 社区开发版本
|
||||||
|
- 满足基本合规问题下，尽可能集成更多软件，优先选择开源组件当前稳定分支的最新版本。
|
||||||
|
- 及时跟进上游社区动态，合并开源软件新特性版本。
|
||||||
|
|
||||||
|
### 1.3 软件分级与兼容性原则
|
||||||
|
|
||||||
|
| **级别** | **范围** | **原则** |
|
||||||
|
| -------- | --------------------------------------- | ------------------------------------------------------------ |
|
||||||
|
| 一级 | kernel、glibc、gcc、zlib等系统核心组件 | API和ABI主版本的生命周期内保持稳定，并且在接下来的一个主版本中也尽量保持稳定 |
|
||||||
|
| 二级 | dbus、oepnssl、bzip2、systemd等基础软件 | API和ABI在单个主版本的生存周期内保持稳定，依赖的应用程序在单个主版本生命周期内原则上无需重大修改 |
|
||||||
|
| 三级 | 其他应用软件等 | API和ABI在单个主版本的生存周期内不强制保持稳定，存在依赖关系的应用程序保持联动升级 |
|
||||||
|
|
||||||
|
## 2. 具体流程
|
||||||
|
|
||||||
|
1. 依据“软件项目选型策略"挑选需要引入的新项目
|
||||||
|
|
||||||
|
2. 依据"软件版本选型策略"挑选该项目需要引入的某一个版本
|
||||||
|
|
||||||
|
3. 输出“项目选型报告”，包含新项目的合规性、兼容性、重要程度、活跃度、质量、安全性具体情况，以及选中版本的新特性、兼容性、影响域、其他发行版中版本情况对比等内容；
|
||||||
|
|
||||||
|
4. 技术委员会通过后按以下流程开展具体工作
|
||||||
|
|
||||||
|
### 2.1 获取软件包的项目地址
|
||||||
|
|
||||||
|
获取项目地址用于查看软件包当前的项目详情、开发状态、编译安装、使用说明等相关内容
|
||||||
|
|
||||||
|
可以从以下几个方法去获取软件包的项目地址：
|
||||||
|
|
||||||
|
#### 2.1.1 debian社区的软件包追踪平台
|
||||||
|
|
||||||
|
基本上绝大部分的软件包都可以在debian社区的软件包追踪平台（[tracker.debian.org](https://tracker.debian.org/)）上找到
|
||||||
|
|
||||||
|
例如：查找`libnftnl`软件包
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
如上图，可以通过右上角的homepage信息去获取软件包的项目地址；
|
||||||
|
|
||||||
|
#### 2.1.2 dsc文件
|
||||||
|
|
||||||
|
可以在debian社区（[tracker.debian.org](https://tracker.debian.org/)）、ubuntu（https://launchpad.net）等平台查看软件包的dsc文件，dsc文件中可能有描述当前软件包的项目地址信息。
|
||||||
|
|
||||||
|
如：`libnftnl`在debian社区查看软件包dsc文件（https://deb.debian.org/debian/pool/main/libn/libnftnl/libnftnl_1.2.3-1.dsc）：
|
||||||
|
|
||||||
|
```Bash
|
||||||
|
# 去除gpg签名信息，方便查看
|
||||||
|
Format: 3.0 (quilt)
|
||||||
|
Source: libnftnl
|
||||||
|
Binary: libnftnl11, libnftnl-dev, libnftnl-dev-doc
|
||||||
|
Architecture: linux-any all
|
||||||
|
Version: 1.2.3-1
|
||||||
|
Maintainer: Debian Netfilter Packaging Team <pkg-netfilter-team@lists.alioth.debian.org>
|
||||||
|
Uploaders: Arturo Borrero Gonzalez <arturo@debian.org>
|
||||||
|
Homepage: https://git.netfilter.org/libnftnl
|
||||||
|
Standards-Version: 4.6.0
|
||||||
|
Vcs-Browser: https://salsa.debian.org/pkg-netfilter-team/pkg-libnftnl
|
||||||
|
Vcs-Git: https://salsa.debian.org/pkg-netfilter-team/pkg-libnftnl.git
|
||||||
|
Build-Depends: debhelper-compat (= 13), doxygen, libmnl-dev, libtool, pkg-config
|
||||||
|
Package-List:
|
||||||
|
libnftnl-dev deb libdevel optional arch=linux-any
|
||||||
|
libnftnl-dev-doc deb doc optional arch=all
|
||||||
|
libnftnl11 deb libs optional arch=linux-any
|
||||||
|
Checksums-Sha1:
|
||||||
|
ba4f824a4e700441aa8475d4ef7f2138e2871c5e 395208 libnftnl_1.2.3.orig.tar.bz2
|
||||||
|
54aaab06ab27de4dbd0c1f748d59c52c145ab70a 833 libnftnl_1.2.3.orig.tar.bz2.asc
|
||||||
|
c8e0cbe989bd9b2adad849500e917fd9e178e696 10308 libnftnl_1.2.3-1.debian.tar.xz
|
||||||
|
Checksums-Sha256:
|
||||||
|
e916ea9b79f9518560b9a187251a7c042442a9ecbce7f36be7908888605d0255 395208 libnftnl_1.2.3.orig.tar.bz2
|
||||||
|
473149a45368d188850e1fd5859d295ec941818b04b6544f839e2d91498238c8 833 libnftnl_1.2.3.orig.tar.bz2.asc
|
||||||
|
d15762d170077e22d06e06c4b9d7c57b4366f89ab446a30ce564e874beab4d56 10308 libnftnl_1.2.3-1.debian.tar.xz
|
||||||
|
Files:
|
||||||
|
6d50ff1cae246cc038ff7c851b1f5eb8 395208 libnftnl_1.2.3.orig.tar.bz2
|
||||||
|
d9ad712df9dddf559c01f111b24c6b04 833 libnftnl_1.2.3.orig.tar.bz2.asc
|
||||||
|
d3e077f0fc8b00d912c289579d77bf8f 10308 libnftnl_1.2.3-1.debian.tar.xz
|
||||||
|
```
|
||||||
|
|
||||||
|
如高亮处：
|
||||||
|
|
||||||
|
- **Homepage** ：项目地址
|
||||||
|
|
||||||
|
- **Vcs-Browser** ：版本控制系统浏览平台（类似于github、gitee、gitlab等平台）
|
||||||
|
|
||||||
|
- **Vcs-Git** ：git仓库地址
|
||||||
|
|
||||||
|
#### 2.1.3 debian/control文件
|
||||||
|
|
||||||
|
首先先从debian社区、ubuntu社区（launchpad.net）任意下载源码包，并解压缩。
|
||||||
|
|
||||||
|
```Bash
|
||||||
|
# 从ubuntu社区（launchpad.net）平台下载源码包
|
||||||
|
# 也可以通过添加deb-src源的方式使用apt-source来下载源码
|
||||||
|
# 使用dget需要安装devscripts
|
||||||
|
dget -x https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/libnftnl/1.2.3-1/libnftnl_1.2.3-1.dsc
|
||||||
|
|
||||||
|
# 进入到解压缩目录
|
||||||
|
cd libnftnl-1.2.3
|
||||||
|
```
|
||||||
|
|
||||||
|
查看`debian/control`文件，查找是否有`Homepage`、`Vcs-Git`、`Vcs-Browser`等相关字段
|
||||||
|
|
||||||
|
如：
|
||||||
|
|
||||||
|
```Bash
|
||||||
|
$ grep -E "^(Homepage|Vcs-*)" debian/control
|
||||||
|
Homepage: https://git.netfilter.org/libnftnl
|
||||||
|
Vcs-Git: https://salsa.debian.org/pkg-netfilter-team/pkg-libnftnl.git
|
||||||
|
Vcs-Browser: https://salsa.debian.org/pkg-netfilter-team/pkg-libnftnl
|
||||||
|
```
|
||||||
|
|
||||||
|
上述高亮处各字段的说明与2.1.2小节的内容一致
|
||||||
|
|
||||||
|
#### 2.1.4 debian/watch文件
|
||||||
|
|
||||||
|
与2.1.3小节一样，需要先下载源码。这次查看的是`debian/watch`文件
|
||||||
|
|
||||||
|
**debian/watch** 文件主要是用来记录上游源码的下载地址（该文件不是必须的，因此在某些源码包中可能没有该文件）
|
||||||
|
|
||||||
|
```Bash
|
||||||
|
$ cat debian/watch
|
||||||
|
version=3
|
||||||
|
opts=pgpsigurlmangle=s/$/.sig/ http://ftp.netfilter.org/pub/libnftnl/libnftnl-(\S+).tar.bz2
|
||||||
|
```
|
||||||
|
|
||||||
|
通过该文件记录的上游源码下载地址，可以找到其对应的项目地址
|
||||||
|
|
||||||
|
如：
|
||||||
|
|
||||||
|
```Bash
|
||||||
|
# 其下载地址一般是ftp或git release下载地址
|
||||||
|
# 如果其下载地址是由别的平台托管的那么可能就无法获悉其项目地址
|
||||||
|
http://ftp.netfilter.org/pub/libnftnl
|
||||||
|
|
||||||
|
# 通过上述地址猜测可能的项目地址是
|
||||||
|
http://netfilter.org/pub/libnftnl
|
||||||
|
```
|
||||||
|
|
||||||
|
### 2.2 获取软件包的版本情况
|
||||||
|
|
||||||
|
通过查看项目地址获悉当前项目的最新稳定版本列表。
|
||||||
|
|
||||||
|
可以通过以下几种方式查看：
|
||||||
|
|
||||||
|
- debian/watch 文件
|
||||||
|
|
||||||
|
在2.1.4小节中如果软件包的有debian/watch文件，可以查看该项目的上游软件包压缩包下载地址。
|
||||||
|
|
||||||
|
```
|
||||||
|
！其下载地址中可能有beta版本，其名字类似于xxxx-beta.tar.gz。一般这种beta版本的源码不应该被选择。
|
||||||
|
```
|
||||||
|
|
||||||
|
- git仓库
|
||||||
|
|
||||||
|
如果是git仓库，可以查看其对应的是否有发布 git release：
|
||||||
|
|
||||||
|
1. 如果有，那么可以在git release页面获取其版本列表
|
||||||
|
|
||||||
|
2. 如果没有，查看其对应的`branch(分支)`、`tag(标记)`是否有相关版本列表信息
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
# 二、构建源码包
|
||||||
|
|
||||||
|
从第一章节中选出待构建软件包的版本以及下载地址。
|
||||||
|
|
||||||
|
如果远端仓库已有项目，需要变更upstream版本，那么请查看第4小节的内容。
|
||||||
|
|
||||||
|
## 1. 下载源码并修改源码目录格式
|
||||||
|
|
||||||
|
下载源码包到本地，并解压缩
|
||||||
|
|
||||||
|
```Bash
|
||||||
|
# 下载源码
|
||||||
|
wget https://www.netfilter.org/pub/libnftnl/libnftnl-1.2.3.tar.bz2
|
||||||
|
|
||||||
|
# 解压缩
|
||||||
|
tar -xaf libnftnl-1.2.3.tar.bz2
|
||||||
|
```
|
||||||
|
|
||||||
|
修改源码目录，使其符合**<source_name>-<source_version>**格式。如：
|
||||||
|
|
||||||
|
```Bash
|
||||||
|
$ ls -al
|
||||||
|
drwxr-x---@ - luzp 10 8月 02:24 libnftnl-1.2.3
|
||||||
|
.rw-rw----@ 395k luzp 10 8月 02:24 libnftnl-1.2.3.tar.bz2
|
||||||
|
```
|
||||||
|
|
||||||
|
## 2. 构建出debian打包目录
|
||||||
|
|
||||||
|
### 2.1 upstream源码包含debian目录
|
||||||
|
|
||||||
|
```
|
||||||
|
！注意：如果上游源码目录中包含debian目录，此时我们需要手动对上游的debian目录进行改名，避免我们再重新生成debian目录时引起别的问题
|
||||||
|
```
|
||||||
|
|
||||||
|
- 备份原有的debian目录
|
||||||
|
|
||||||
|
```Bash
|
||||||
|
mv debian debian-orig
|
||||||
|
```
|
||||||
|
|
||||||
|
- 重新构建debian目录
|
||||||
|
|
||||||
|
```Bash
|
||||||
|
debmake -u <upstream版本号> -r <修订版本号> -t
|
||||||
|
```
|
||||||
|
|
||||||
|
此时，会在源码的同级目录新创建个目录，其格式为<原来的源码目录名称>-<upstream版本号>
|
||||||
|
|
||||||
|
假如：
|
||||||
|
|
||||||
|
源码压缩包是`amdgcn-tools-13.tar.gz`
|
||||||
|
|
||||||
|
```Bash
|
||||||
|
# 解压源码
|
||||||
|
# 解压后的源码目录为amdgcn-tools-13
|
||||||
|
tar -xaf amdgcn-tools-13.tar.gz
|
||||||
|
|
||||||
|
# 进入源码目录，并备份原来的debian目录
|
||||||
|
cd amdgcn-tools-13
|
||||||
|
mv debian debian-orig
|
||||||
|
|
||||||
|
# 重新构建debian目录
|
||||||
|
debmake -u13 -rok1 -t
|
||||||
|
|
||||||
|
# 执行完成之后，会在amdgcn-tools-13同级目录生成一个新的目录
|
||||||
|
# <原来的源码目录>-<upstream版本号>,也就是下面的目录
|
||||||
|
ls amdgcn-tools-13-13
|
||||||
|
```
|
||||||
|
|
||||||
|
### 2.2 直接构建debian目录
|
||||||
|
|
||||||
|
如果上游源码是纯源码，那么直接构建debian目录即可。
|
||||||
|
|
||||||
|
```Bash
|
||||||
|
# 构建debian目录
|
||||||
|
debmake -z tar.bz2
|
||||||
|
```
|
||||||
|
|
||||||
|
- -z 指定源码的压缩包格式
|
||||||
|
- libnftnl-1.2.3.tar.bz2 就指定为 -z tar.bz2
|
||||||
|
|
||||||
|
- 默认的源码压缩格式是tar.gz
|
||||||
|
|
||||||
|
- -b 如果是perl或python的源码包可以指定该参数，为debmake创建出更多配套对应编程语言的文件
|
||||||
|
|
||||||
|
```Bash
|
||||||
|
# 如果是python
|
||||||
|
debmake -b":python3"
|
||||||
|
|
||||||
|
# perl
|
||||||
|
debmake -b":perl"
|
||||||
|
```
|
||||||
|
|
||||||
|
- -t 重新生成上游源码包（即xxx.orig.tar.gz）
|
||||||
|
|
||||||
|
更详细的debmake用法可以查看其man手册
|
||||||
|
|
||||||
|
```Bash
|
||||||
|
man debmake
|
||||||
|
```
|
||||||
|
|
||||||
|
## 3. 修改构建规则
|
||||||
|
|
||||||
|
主要是修改debian目录中的文件。
|
||||||
|
|
||||||
|
### 3.1 control
|
||||||
|
|
||||||
|
`control`文件涉及两个部分的内容：
|
||||||
|
|
||||||
|
#### 3.1.1 源码包部分
|
||||||
|
|
||||||
|
描述当前这个源码包的简要信息，以及构建该源码包的编译依赖等
|
||||||
|
|
||||||
|
其中有几个字段需要注意：
|
||||||
|
|
||||||
|
- **Section**
|
||||||
|
|
||||||
|
描述软件包的类型，用于软件包的分类。比如`mysql-8`应属于`database`
|
||||||
|
|
||||||
|
可选的内容有：
|
||||||
|
|
||||||
|
admin, cli-mono, comm, database, debug, devel, doc, editors, education, electronics, embedded, fonts, games, gnome, gnu-r, gnustep, graphics, hamradio, haskell, httpd, interpreters, introspection, java, javascript, kde, kernel, libdevel, libs, lisp, localization, mail, math, metapackages, misc, net, news, ocaml, oldlibs, otherosfs, perl, php, python, ruby, rust, science, shells, sound, tasks, tex, text, utils, vcs, video, web, x11, xfce, zope
|
||||||
|
|
||||||
|
- **Priority**
|
||||||
|
- 软件包的优先级
|
||||||
|
|
||||||
|
- required 系统必须的包
|
||||||
|
- important 重要的软件包，系统非必须的包，但是希望系统中最好能预装的
|
||||||
|
- standard 标准相对独立的软件包
|
||||||
|
- optional 这是默认优先级选项，除非这个软件包是系统必须的包，否则应该使用该选项
|
||||||
|
|
||||||
|
- **Maintainer**
|
||||||
|
|
||||||
|
需要写成当前openkylin负责该软件包的sig组，如`packaging sig`组的写成`Openkylin Developers <packaging@lists.openkylin.top>`
|
||||||
|
|
||||||
|
- **Vcs-Browser**:
|
||||||
|
|
||||||
|
写成对应的gitee仓库地址， 如 https://gitee.com/openkylin/autoconf
|
||||||
|
|
||||||
|
- **Vcs-Git**
|
||||||
|
|
||||||
|
写成对应的gitee仓库git地址 ，如 https://gitee.com/openkylin/autoconf.git
|
||||||
|
|
||||||
|
- **Build-Depends和**
|
||||||
|
|
||||||
|
编译体系结构相关代码所需要的编译依赖
|
||||||
|
|
||||||
|
- **Build-Depends-Indep**
|
||||||
|
|
||||||
|
编译体系结构无关的代码所需要的编译依赖
|
||||||
|
|
||||||
|
对于**Build-Depends**和**Build-Depends-Indep**可以从项目地址中查找是否有相关编译依赖说明。
|
||||||
|
|
||||||
|
#### 3.1.2 二进制包部分
|
||||||
|
|
||||||
|
描述当前源码包可以被分为哪些二进制包程序。
|
||||||
|
|
||||||
|
常见的分包类型为：
|
||||||
|
|
||||||
|
- lib
|
||||||
|
|
||||||
|
共享库，其二进制包包名一般为 `lib-xxx`
|
||||||
|
|
||||||
|
- dev
|
||||||
|
|
||||||
|
共享库头文件及相关开发文件，其二进制包名一般为`lib-xxx-dev`
|
||||||
|
|
||||||
|
- doc
|
||||||
|
|
||||||
|
软件包的文档
|
||||||
|
|
||||||
|
如果其文档对应的是某个可执行程序的文档，其二进制包包名一般为`xxx-doc`
|
||||||
|
|
||||||
|
如果其文档是某个开发库的文档，其二进制包包名一般为`lib-xxx-doc`
|
||||||
|
|
||||||
|
- bin
|
||||||
|
|
||||||
|
软件包的二进制程序，如编译型语言（比如c/c++）的二进制程序，以及解释型编程语言（比如python、perl）的可执行程序，其二进制包包名一般为其对应的二进制程序名称
|
||||||
|
|
||||||
|
这个分包时，可以结合`debmake`在构建`debian`打包目录时一起使用，如：
|
||||||
|
|
||||||
|
```Bash
|
||||||
|
# 软件包名称为 foo ， 其提供二进制程序与二进制程序的文档
|
||||||
|
debmake -b"foo:bin,foo-doc:doc"
|
||||||
|
|
||||||
|
# 软件包名称为 libfoo ， 是一个开发库源码，其提供开发库与开发库的文档
|
||||||
|
debmake -b"libfoo:lib,libfoo-doc:doc"
|
||||||
|
|
||||||
|
# 执行完之后，会自动将各个二进制包信息模板写入到debian/control文件中
|
||||||
|
```
|
||||||
|
|
||||||
|
### 3.2 rules
|
||||||
|
|
||||||
|
软件包的编译构建规则
|
||||||
|
|
||||||
|
### 3.3 changelog
|
||||||
|
|
||||||
|
修改软件包的版本号，格式为：<upstream_version>-<revisions>
|
||||||
|
|
||||||
|
一般来说，对于openkylin社区，使用`ok1`作为第一次revisions，如：
|
||||||
|
|
||||||
|
```Bash
|
||||||
|
autoconf (2.71-ok1) yangtze; urgency=low
|
||||||
|
|
||||||
|
* Build for openKylin.
|
||||||
|
|
||||||
|
-- Lu zhiping <luzhiping@kylinos.cn> Fri, 26 Aug 2022 15:25:09 +0800
|
||||||
|
```
|
||||||
|
|
||||||
|
### 3.4 source/format
|
||||||
|
|
||||||
|
必须将源码包的格式设为`quilt`格式
|
||||||
|
|
||||||
|
```Bash
|
||||||
|
echo "3.0 (quilt)" > debian/source/format
|
||||||
|
```
|
||||||
|
|
||||||
|
```Bash
|
||||||
|
echo "3.0 (quilt)" > debian/source/format
|
||||||
|
```
|
||||||
|
|
||||||
|
### 3.5 其他文件
|
||||||
|
|
||||||
|
xxx.install
|
||||||
|
|
||||||
|
xxx.doc
|
||||||
|
|
||||||
|
xxx.symbols
|
||||||
|
|
||||||
|
xxx.manpages
|
||||||
|
|
||||||
|
### 3.6 应用其他OS发行版的补丁
|
||||||
|
|
||||||
|
如果其他OS发行版有该软件包的补丁，那么我们需要分析考虑是否应用他们的补丁。
|
||||||
|
|
||||||
|
可以先从以下方面去考虑是否应用其他OS发行版的补丁：
|
||||||
|
|
||||||
|
- 补丁的修复内容是什么？补丁没能被上游社区吸收的原因，是否是无关紧要的补丁？
|
||||||
|
|
||||||
|
- 是否是以前的旧版本才有的补丁，新版本是否已经集成？
|
||||||
|
|
||||||
|
- 是否是重大漏洞修复补丁？
|
||||||
|
|
||||||
|
- 是否是特定OS发行版才需要的补丁？
|
||||||
|
|
||||||
|
- 如果不应用补丁是否出现编译问题，安装是否有问题？
|
||||||
|
|
||||||
|
```
|
||||||
|
而且，应用上游社区的patches最好是在构建出git仓库之后再应用patches，这样能在git commit中保留上游社区patch的信息
|
||||||
|
```
|
||||||
|
|
||||||
|
下面的内容是在第五章节构建出git仓库之后应用patch的步骤：
|
||||||
|
|
||||||
|
如果需要应用上游社区的patch，最好是保留他们patch信息的内容与作者信息等。可以通过git工具直接应用上游社区的patch：
|
||||||
|
|
||||||
|
- git am应用patch
|
||||||
|
|
||||||
|
git am应用patch会自动保留patch的信息
|
||||||
|
|
||||||
|
```Bash
|
||||||
|
git am xxxx.patch
|
||||||
|
```
|
||||||
|
|
||||||
|
- git apply应用patch
|
||||||
|
|
||||||
|
但是有些patch的信息格式不是完全适用于git am，那么可以使用git apply导入patch，然后再进行commit添加patch信息
|
||||||
|
|
||||||
|
```Bash
|
||||||
|
# 导入patch信息
|
||||||
|
git apply xxx.patch
|
||||||
|
|
||||||
|
# 添加改动
|
||||||
|
git add .
|
||||||
|
|
||||||
|
# 在编辑框中填写patch的相关信息，如
|
||||||
|
# patch的作者，patch的内容等
|
||||||
|
git commit
|
||||||
|
```
|
||||||
|
|
||||||
|
导入patch之后，想对新导入patch的内容进行编译测试，那么可以使用gbp工具来生成新的源码（新的dsc文件）
|
||||||
|
|
||||||
|
```Bash
|
||||||
|
# 修改changelog新增版本号
|
||||||
|
vim debian/changelog
|
||||||
|
|
||||||
|
# 编译源码，会生成新的dsc文件
|
||||||
|
gbp buildpackage -S -sa -nc --git-prisine-tar --git-ignore-branch
|
||||||
|
```
|
||||||
|
|
||||||
|
## 4. 导入上游upstream源码
|
||||||
|
|
||||||
|
如果远端仓库已有项目，需要变更upstream版本。
|
||||||
|
|
||||||
|
（1）从上游社区下载源码压缩包
|
||||||
|
|
||||||
|
（2）对源码压缩包重新加压缩使其符合`<package-name>_<pacakge-version>.orig.tar.[gz|xz|bz2]`格式
|
||||||
|
|
||||||
|
```Bash
|
||||||
|
#例如：
|
||||||
|
# 从上游源码社区获取的源码压缩包为 requests-2.27.1.tar.gz
|
||||||
|
# 首先解压源码
|
||||||
|
tar -xaf requests-2.27.1.tar.gz
|
||||||
|
|
||||||
|
# 修改源码目录为 <package-name>-<package-version>
|
||||||
|
# 假如从上游社区的源码压缩包解压出来的目录是requests
|
||||||
|
mv requests requests-2.27.1
|
||||||
|
|
||||||
|
# 重新压缩,使其符合 <package-name>_<pacakge-version>.orig.tar.[gz|xz|bz2]
|
||||||
|
tar -czf requests-2.27.1 requests-2.27.1.orig.tar.gz
|
||||||
|
```
|
||||||
|
|
||||||
|
（3）克隆gitee远端仓库源码到本地，进入源码目录
|
||||||
|
|
||||||
|
```Bash
|
||||||
|
# 克隆远端仓库
|
||||||
|
git clone git@gitee.com:openkylin/requests.git
|
||||||
|
|
||||||
|
# 进入源码目录
|
||||||
|
cd requests
|
||||||
|
```
|
||||||
|
|
||||||
|
（4）变更upstream源码
|
||||||
|
|
||||||
|
参考[麒麟源码包git工作流](https://uq76pac93x.feishu.cn/docs/doccnvI4ASK0u7gMy9Zs0Dfbjsf#RP6nmh) 的第六章节《更新upstream版本》
|
||||||
|
|
||||||
|
- a. 导入上游upstream版本（第二步生成的压缩包）
|
||||||
|
|
||||||
|
- - ```Bash
|
||||||
|
gbp import-orig requests-2.27.1.orig.tar.gz --no-merge --pristine-tar --upstream-branch=upstream
|
||||||
|
git checkout upstream
|
||||||
|
git push
|
||||||
|
git push --tags
|
||||||
|
```
|
||||||
|
|
||||||
|
- b. 筛选旧版本patch （结合[麒麟源码包git工作流](https://uq76pac93x.feishu.cn/docs/doccnvI4ASK0u7gMy9Zs0Dfbjsf#EAbqM8) 6.3.3小节进行）
|
||||||
|
|
||||||
|
- - 如果patch是研发的patch，那么需要与相关研发确认该patch在新的upstream源码中是否还需要
|
||||||
|
- 如果patch是其他OS发行版的patch，那么需要结合OS发行版的最新版本源码中确认是否还需要该patch
|
||||||
|
|
||||||
|
- c. 引入其他OS发行版的patch
|
||||||
|
|
||||||
|
- - 可以参考3.6小节《应用其他OS发行版的补丁》。
|
||||||
|
|
||||||
|
- 使用git am或git apply 或其他方式导入其他OS发行版的patch
|
||||||
|
|
||||||
|
- d. 修改debian目录的其他编译构建文件
|
||||||
|
|
||||||
|
- - debian/control
|
||||||
|
- debian/changelog 需保留原有的changelog信息
|
||||||
|
- debian/rules
|
||||||
|
- deiban/其他文件
|
||||||
|
|
||||||
|
修改完成之后，可以按第5小节，先本地编译测试，测试无问题后再推送到远端仓库上。
|
||||||
|
|
||||||
|
## 5. 编译源码包
|
||||||
|
|
||||||
|
完成对debian目录构建规则的完善之后，先基于此编译一轮源码包。会生成dsc文件
|
||||||
|
|
||||||
|
```Bash
|
||||||
|
# 切到开发分支上
|
||||||
|
git checkout openkylin/yangtze
|
||||||
|
# 在源码目录执行
|
||||||
|
dpkg-source -b .
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
# 三、编译
|
||||||
|
|
||||||
|
根据上一章节的内容构建出源码包之后，进行编译。
|
||||||
|
|
||||||
|
可以下载一个openkylin的chroot环境，在chroot环境中进行编译调试。
|
||||||
|
|
||||||
|
x86的chroot：http://files.build.openkylin.top/51159/chroot-openkylin-yangtze-amd64.tar.gz
|
||||||
|
|
||||||
|
riscv的chroot: http://files.build.openkylin.top/51197/chroot-openkylin-yangtze-riscv64.tar.gz
|
||||||
|
|
||||||
|
在这一阶段会对debian打包目录中的打包构建规则进行不断的修改和优化，直至打包出一个完整可安装的二进制包。
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
# 四、安装测试
|
||||||
|
|
||||||
|
简单测试编译出的二进制程序是否可安装，安装之后系统是否正常等
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
# 五、构建git仓库
|
||||||
|
|
||||||
|
## 1. 创建gitee仓库
|
||||||
|
|
||||||
|
fork openkylin的community仓库
|
||||||
|
|
||||||
|
```Bash
|
||||||
|
# fork到个人仓库之后，克隆个人仓库到本地
|
||||||
|
git clone git@gitee.com:<username>/community.git
|
||||||
|
|
||||||
|
# 然后在对应的sig组sig.yaml文件中添加源码包名称
|
||||||
|
# 例如为packaging sig新增软件包，source-name 需写实际的软件包名称
|
||||||
|
echo "- <source-name>" >> sig/packaging/sig.yaml
|
||||||
|
|
||||||
|
# 然后提交改动，推送到个人仓库
|
||||||
|
git add sig/packaging/sig.yaml
|
||||||
|
git commit -m "新增xxx软件包"
|
||||||
|
git push origin master
|
||||||
|
```
|
||||||
|
|
||||||
|
在gitee网页端创建PR，然后由community项目负责人审查，审查通过后CI平台会自动创建对应的git仓库
|
||||||
|
|
||||||
|
## 2. 构建git仓库
|
||||||
|
|
||||||
|
对第二章节构建出来的源码包进行git仓库的构建。
|
||||||
|
|
||||||
|
- 下载工具
|
||||||
|
|
||||||
|
按照[source-packaging](https://gitlab2.kylin.com/luxx/packaging-tools#源码反向构建工具-source-packing)工具的使用方法下载工具和相关依赖的安装
|
||||||
|
|
||||||
|
- 构建git仓库
|
||||||
|
|
||||||
|
```Bash
|
||||||
|
./source-packing import-to-git --dsc-file sqlite3_3.31.1-ok1.dsc --packaging-branch yhkylin/v101
|
||||||
|
```
|
||||||
|
|
||||||
|
更详细的git工作流可以参考[麒麟源码包git工作流](https://uq76pac93x.feishu.cn/docs/doccnvI4ASK0u7gMy9Zs0Dfbjsf#0OthhB)
|
||||||
|
|
||||||
|
## 3. 关联远端仓库，并推送到gitee
|
||||||
|
|
||||||
|
需要包在第三章节编译、第四章节安装测试没问题了之后，才推送到gitee仓库上
|
||||||
|
|
||||||
|
```Bash
|
||||||
|
# 进入到第二步构建出的源码仓库
|
||||||
|
cd sqlite3
|
||||||
|
# 关联远端仓库并推送到远端仓库
|
||||||
|
git remote add origin git@gitee.com:openkylin/sqlte3.git
|
||||||
|
git push --all && git push --tags
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
# 六、其他内容
|
||||||
|
|
||||||
|
1. gitee的ci流程简要描述：
|
||||||
|
|
||||||
|
```Bash
|
||||||
|
1. 软件包第一次推送：
|
||||||
|
maintainer首次将包通过push的方式推送到gitee的仓库上，此时ci平台会将其打包发送到okbs编译平台进行编译，当前的编译地址是（https://build.openkylin.top/~cibot/+archive/openkylin/citest/+packages）
|
||||||
|
|
||||||
|
2. 后续的修改贡献：
|
||||||
|
开发者需要fork仓库到个人仓库中，然后在个人仓库上进行开发修改，源码修改完毕后再修改changelog新增版本号，然后提交PR到原始仓库。
|
||||||
|
|
||||||
|
maintainer审查PR，PR审查通过后，CI平台自动对当前的PR进行打包发送到OKBS编译平台进行编译，编译结果将会以评论的方式添加到对应的PR中，maintainer根据编译结果以及CI平台的门禁检查结果来考虑是否接收该PR
|
||||||
|
```
|
||||||
|
|
||||||
|
2. 各发行版源地址，以gvfs为例：
|
||||||
|
|
||||||
|
Debian 11: https://tracker.debian.org/pkg/gvfs
|
||||||
|
|
||||||
|
Ubuntu 22.04: https://launchpad.net/ubuntu/+source/gvfs
|
||||||
|
|
||||||
|
Fedora 36: https://src.fedoraproject.org/rpms/gvfs
|
||||||
|
|
||||||
|
Arch: https://archlinux.org/packages/extra/x86_64/gvfs/
|
||||||
|
|
||||||
|
Deepin: https://ftp.sjtu.edu.cn/deepin/pool/
|
||||||
|
|
||||||
|
openEuler: https://gitee.com/src-openeuler/gvfs
|
||||||
Loading…
Reference in New Issue