From 6e6a07e4951d24faa7a91e941b2d82afb2b6942a Mon Sep 17 00:00:00 2001
From: jlspcdd1227dd <12046126+jlspcdd1227dd@user.noreply.gitee.com>
Date: Wed, 22 Mar 2023 07:24:17 +0000
Subject: [PATCH] update
 en/Community-Developer-Guides/Source_Independent_Selection_Build.md.

Signed-off-by: jlspcdd1227dd <12046126+jlspcdd1227dd@user.noreply.gitee.com>
---
 .../Source_Independent_Selection_Build.md     | 1099 ++++++++---------
 1 file changed, 489 insertions(+), 610 deletions(-)

diff --git a/en/Community-Developer-Guides/Source_Independent_Selection_Build.md b/en/Community-Developer-Guides/Source_Independent_Selection_Build.md
index 6e732908..7ef616c3 100644
--- a/en/Community-Developer-Guides/Source_Independent_Selection_Build.md
+++ b/en/Community-Developer-Guides/Source_Independent_Selection_Build.md
@@ -1,566 +1,470 @@
-# OpenKylin source code independent selection and construction process
+# openKylin source code independent selection build process
 
-# 1. Selection of software package version number
+# I. Package version number selection
 
-## 1. Selection strategy
+## 1. selection strategy
 
 ### 1.1 Software project selection strategy
 
-![输入图片说明](media/rId21.png){width="5.833333333333333in"
-height="2.7753904199475063in"}- Continued active introduction of full
-\"A\" software (versions)
+! [Enter image description](assets/openKylin%E6%BA%90%E7%A0%81%E8%87%AA%E4%B8%BB%E9%80%89%E5%9E%8B%E6%9E%84%E5%BB%BA%E6%B5%81%E7%A8%8B/%E8%BD%AF%E4% BB%B6%E9%A1%B9%E7%9B%AE%E9%80%89%E5%9E%8B%E7%AD%96%E7%95%A5.png)
+- Continue to actively introduce full "A" software (version)
 
--   Encourage the introduction of only \"A\" and \"B\" software
-    (version)tory-view-113483.html
+- Encourage the introduction of "A" and "B" software only (version) tory-view-113483.html
 
--   Cautiously introduce \"C\" software (version)
+- Cautiously introduce software with "C" (version)
 
--   Refuse to introduce/delete software (version) containing \"D\" or
-    \"C \>= 3\" in time
+- Reject/delete software (version) with "D" or "C >= 3" in time
 
 ### 1.2 Software version selection strategy
 
--   Long-term support version (temporarily openKylin has not yet
-    determined a long-term support version, 1.0 is currently not a
-    long-term support version)
-    -   Taking into account both quality and stability, give priority to
-        the widely used version of the mainstream OS.
-    -   Compatibility lists are not affected after the upgrade.
-    -   During the life cycle of the same version, no major version
-        changes are made, and only features and patch rounds are used to
-        solve quality problems.
--   Community-developed version
-    -   To meet the basic compliance issues, integrate as much software
-        as possible, and give priority to the latest version of the
-        current stable branch of the open source component.
-    -   Follow up the dynamics of the upstream community in a timely
-        manner, and merge new feature versions of open source software.
+- Long-term support version (for the time being, openKylin does not have a long-term support version, 1.0 is not a long-term support version at the moment)
+  - Give priority to the version widely used by mainstream OS, taking into account both quality and stability.
+  - The compatibility list is not affected by the upgrade.
+  - No major version changes during the life cycle of the same version, only feature and patch rounds to solve quality problems.
+
+- Community development version
+  - Meet the basic compliance issues, integrate as much software as possible, giving priority to the latest version of the current stable branch of open source components.
+  - Follow up on upstream community dynamics in a timely manner and merge new feature versions of open source software.
 
 ### 1.3 Software classification and compatibility principles
 
-  -----------------------------------------------------------------------------
-  **level**   **scope**                 **in principle**
-  ----------- ------------------------- ---------------------------------------
-  level one   kernel, glibc, gcc, zlib  API and ABI are stable for the lifetime
-              and other system core     of a major version, and try to be
-              components                stable for the next major version
+| **Level** | **Scope** | **Principles** |
+| -------- | --------------------------------------- | ------------------------------------------------------------ |
+| Level 1 | kernel, glibc, gcc, zlib, and other core system components | APIs and ABI remain stable for the lifetime of the main release, and as much as possible for the next main release |
+| Level 2 | Base software such as dbus, oepnssl, bzip2, systemd, etc. | APIs and ABIs remain stable for the lifetime of a single major release, and dependent applications do not require major changes in principle for the lifetime of a single major release | Level 3 | Other applications, etc. | APIs and ABIs remain stable for the lifetime of a single major release.
+| The API and ABI are not forced to remain stable during the life cycle of a single major version, and dependent applications are upgraded inline.
 
-  Secondary   Basic software such as    The API and ABI remain stable during
-              dbus, oepnssl, bzip2,     the life cycle of a single major
-              systemd, etc.             version, and dependent applications do
-                                        not require major modifications in
-                                        principle during the life cycle of a
-                                        single major version
+## The specific process
 
-  Level three other application         API and ABI are not forced to remain
-              software etc.             stable during the life cycle of a
-                                        single major version, and applications
-                                        with dependencies are kept linked to
-                                        upgrade
-  -----------------------------------------------------------------------------
+1. select the new projects to be introduced according to the "Software Project Selection Policy". 2.
 
-## 2. Specific process
+2. select a version of the project according to the "software version selection policy"
 
-1.  Select new projects to be introduced according to the \"software
-    project selection strategy\"
+3. output the "project selection report", including the compliance, compatibility, importance, activity, quality, security details of the new project, as well as the new features of the selected version, compatibility, impact domain, comparison of versions in other distributions, etc.
 
-2.  According to the \"software version selection strategy\", select a
-    version that needs to be introduced in the project
+4. the technical committee adopted the following process to carry out specific work
 
-3.  Output the \"project selection report\", including the compliance,
-    compatibility, importance, activity, quality, and security details
-    of the new project, as well as the new features, compatibility,
-    impact domain, and versions in other releases of the selected
-    version Situation comparison etc.;
+### 2.1 Obtain the project address of the package
 
-4.  After the approval of the technical committee, the specific work
-    will be carried out according to the following procedures
+The project address is used to view the current project details, development status, compilation and installation, instructions, etc. of the package
 
-### 2.1 Get the project address of the software package
+There are several ways to obtain the project address of the package.
 
-Obtaining the project address is used to view the current project
-details, development status, compilation and installation, usage
-instructions and other related content of the software package
+#### 2.1.1 The debian community's package tracking platform
 
-You can get the project address of the software package in the following
-ways:
+Most packages can be found on the debian community's package tracker ([tracker.debian.org](https://tracker.debian.org/))
 
-#### 2.1.1 The package tracking platform of the debian community
+For example, to find the `libnftnl` package
 
-Basically most of the packages can be found on the debian community\'s
-package tracking platform (
-[tracker.debian.org](https://tracker.debian.org/) )
+! [Enter image description](assets/openKylin%E6%BA%90%E7%A0%81%E8%87%AA%E4%B8%BB%E9%80%89%E5%9E%8B%E6%9E%84%E5%BB%BA%E6%B5%81%E7%A8%8B/debian%E7%A4% BE%E5%8C%BA%E7%9A%84%E8%BD%AF%E4%BB%B6%E5%8C%85%E8%BF%BD%E8%B8%AA%E5%B9%B3%E5%8F%B0%E7%A4%BA%E4%BE%8B.png)
 
-Example: Find `libnftnl `package
-
-![输入图片说明](media/rId29.png){width="5.833333333333333in"
-height="5.719400699912511in"}
-
-Enter a picture description
-
-As shown above, you can get the project address of the software package
-through the homepage information in the upper right corner;
+The project address of the package can be accessed through the homepage information in the upper right corner, as shown above.
 
 #### 2.1.2 dsc file
 
-view the dsc file of the software package on platforms such as the
-debian community ( [tracker.debian.org ) and ubuntu
-(https://launchpad.net). The dsc file may contain project address
-information describing the current software
-package.](https://tracker.debian.org/)
+The dsc file of a package can be viewed on the debian community ([tracker.debian.org](https://tracker.debian.org/)), ubuntu (https://launchpad.net), etc. The dsc file may contain information describing the project address of the current package .
 
-For example: `libnftnl `Check the package [dsc file in the debian
-community](https://deb.debian.org/debian/pool/main/libn/libnftnl) (the
-following uses [version
-1.1.2-2](https://deb.debian.org/debian/pool/main/libn/libnftnl/libnftnl_1.1.2-2.dsc)
-as an example):
+For example: `libnftnl` in the debian community to view the package [dsc file](https://deb.debian.org/debian/pool/main/libn/libnftnl) (hereinafter in [version 1.1.2-2](https://deb.debian.org/)) debian/pool/main/libn/libnftnl/libnftnl_1.1.2-2.dsc) as an example).
 
-    # Remove gpg signature information for easy viewing 
-    Format: 3.0 ( quilt ) 
-    Source: libnftnl 
-    Binary: libnftnl11, libnftnl-dev 
-    Architecture: linux-any 
-    Version: 1.1.2-2 
-    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.2.1 
-    Vcs-Browser: https://salsa.debian .org/pkg-netfilter-team/pkg-libnftnl 
-    Vcs-Git: https://salsa.debian.org/pkg-netfilter-team/pkg-libnftnl 
-    Build-Depends: debhelper ( > = 11 ) , libmnl-dev, libtool, pkg-config 
-    Package-List:
-     libnftnl-dev deb libdevel optional arch=linux-any
-     libnftnl11 deb libs optional arch=linux-any 
-    Checksums-Sha1:
-     c0f880588fabaa845a88fb5a2bdad0dea7481857 366014 libnftnl_1.1.2.orig.tar.bz2
-     0a9063e79191955fbf59482d75c7bfb62aded816 912 libnftnl_1.1.2.orig.tar.bz2.asc
-     505f8b44e3adb574dc3cf657580e9d73f0b0a853 8772 libnftnl_1.1.2-2.debian.tar.xz 
-    Checksums-Sha256:
-     a5c7b7a6c13c9c5898b13fcb1126fefce2015d5a96d7c354b19aaa40b6aece5d 366014 libnftnl_1.1.2.orig.tar.bz2
-     4178552d7ad210e9f17df3c079ac6de032f62c72774d59bfac404a023d48950b 912 libnftnl_1.1.2.orig.tar.bz2.asc
-     4ef80a0c344b23624d24b7dd4be1b73a7b96d86089813c545705f8093067ce13 8772 libnftnl_1.1.2-2.debian.tar.xz 
-    Files:
-     14093a238d5025d4a452e6d1cef88c58 366014 libnftnl_1.1.2.orig.tar.bz2
-     e10dcb9138261d92e7569bd72b809a28 912 libnftnl_1.1.2.orig.tar.bz2.asc
-     518ff0360f67c8031a31792a257a5c3b 8772 libnftnl_1.1.2-2.debian.tar.xz
-
-As highlighted:
-
--   **Homepage** : project address
-
--   **Vcs-Browser** : version control system browsing platform (similar
-    to github, gitee, gitlab and other platforms)
-
--   **Vcs-Git** : git warehouse address
-
-#### 2.1.3 debian/control file
-
-First, download any source package from the debian community and ubuntu
-community (launchpad.net) and decompress it.
-
-    #Download the source code package from the ubuntu community (launchpad.net) platform 
-    # You can also use apt-source to download the source code by adding the deb-src source 
-    # To use dget, you need to install devscripts 
-    dget -x https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/libnftnl/1.2.3-1/libnftnl_1.2.3-1.dsc 
-
-    # Enter the decompression directory 
-    cd libnftnl-1.2.3
-
-Check `the debian/control `file to find out whether there are related
-fields such as `Homepage `, `Vcs-Git `, `Vcs-Browser , etc.`
-
-like:
-
-    $ 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
-
-The descriptions of the fields highlighted above are consistent with
-those in Section 2.1.2
-
-#### 2.1.4 debian/watch file
-
-As in Section 2.1.3, you need to download the source code first. This
-time I checked `the debian/watch `file
-
-**The debian/watch** file is mainly used to record the download address
-of the upstream source code (this file is not necessary, so it may not
-exist in some source code packages)
-
-    $ cat debian/watch 
-    version = 3 
-    opts = pgpsigurlmangle=s/$/.sig/ http://ftp.netfilter.org/pub/libnftnl/libnftnl- ( \S+ ) .tar.bz2
-
-Through the upstream source code download address recorded in this file,
-you can find the corresponding project address
-
-like:
-
-    # Its download address is generally ftp or git release download address 
-    # If its download address is hosted by another platform, it may not be possible to know its project address 
-    http://ftp.netfilter.org/pub/libnftnl 
-
-    # Guess from the above address A possible project address is 
-    http://netfilter.org/pub/libnftnl
-
-### 2.2 Get the version of the software package
-
-Get a list of the latest stable versions of the current project by
-viewing the project address.
-
-It can be viewed in the following ways:
-
--   debian/watch file
-
-In section 2.1.4, if the software package has a debian/watch file, you
-can check the download address of the upstream software package
-compressed package of the project.
-
-    ! There may be a beta version in its download address, and its name is similar to xxxx-beta.tar.gz. Generally, the source code of this kind of beta version should not be selected.
-
--   git repository
-
-If it is a git warehouse, you can check whether its corresponding git
-release has been released:
-
-1.  If so, you can get its version list on the git release page
-
-2.  If not, check whether the corresponding `branch (branch) `and
-    `tag (tag) `have relevant version list information
-
-# 2. Build the source code package
-
-Select the version of the software package to be built and the download
-address from the first chapter.
-
-If there is an existing project in the remote warehouse and the upstream
-version needs to be changed, please refer to Section 4.
-
-## 1. Download the source code and modify the format of the source code directory
-
-Download the source package to local and unzip it
-
-    # Download source code 
-    wget https://www.netfilter.org/pub/libnftnl/libnftnl-1.2.3.tar.bz2 
-
-    # Unzip 
-    tar -xaf libnftnl-1.2.3.tar.bz2
-
-Modify the source directory to conform to the **-** format. like:
-
-    $ ls -al 
-    drwxr -x ---@    - luzp 10 Aug 02:24 libnftnl-1.2.3.rw-rw----@395k 
-    luzp 10 Aug 02:24 libnftnl-1.2.3.tar.bz2
-
-## 2. Build the debian packaging directory
-
-### 2.1 The upstream source code contains the debian directory
-
-    ! Note: If the upstream source code directory contains the debian directory, we need to manually rename the upstream debian directory to avoid other problems when we regenerate the debian directory
-
--   Backup the original debian directory
-
-```{=html}
-<!-- -->
+```Bash
+# Remove gpg signature information for easy viewing
+Format: 3.0 (quilt)
+Source: libnftnl
+Binary: libnftnl11, libnftnl-dev
+Architecture: linux-any
+Version: 1.1.2-2
+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.2.1
+Vcs-Browser: https://salsa.debian.org/pkg-netfilter-team/pkg-libnftnl
+Vcs-Git: https://salsa.debian.org/pkg-netfilter-team/pkg-libnftnl
+Build-Depends: debhelper (>= 11), libmnl-dev, libtool, pkg-config
+package-list:
+ libnftnl-dev deb libdevel optional arch=linux-any
+ libnftnl11 deb libs optional arch=linux-any
+Checksums-Sha1:
+ c0f880588fabaa845a88fb5a2bdad0dea7481857 366014 libnftnl_1.1.2.orig.tar.bz2
+ 0a9063e79191955fbf59482d75c7bfb62aded816 912 libnftnl_1.1.2.orig.tar.bz2.asc
+ 505f8b44e3adb574dc3cf657580e9d73f0b0a853 8772 libnftnl_1.1.2-2.debian.tar.xz
+Checksums-Sha256:
+ a5c7b7a6c13c9c5898b13fcb1126fefce2015d5a96d7c354b19aaa40b6aece5d 366014 libnftnl_1.1.2.orig.tar.bz2
+ 4178552d7ad210e9f17df3c079ac6de032f62c72774d59bfac404a023d48950b 912 libnftnl_1.1.2.orig.tar.bz2.asc
+ 4ef80a0c344b23624d24b7dd4be1b73a7b96d86089813c545705f8093067ce13 8772 libnftnl_1.1.2-2.debian.tar.xz
+Files:
+ 14093a238d5025d4a452e6d1cef88c58 366014 libnftnl_1.1.2.orig.tar.bz2
+ e10dcb9138261d92e7569bd72b809a28 912 libnftnl_1.1.2.orig.tar.bz2.asc
+ 518ff0360f67c8031a31792a257a5c3b 8772 libnftnl_1.1.2-2.debian.tar.xz
 ```
-    mv debian debian-orig
 
--   Rebuild the debian directory
 
-```{=html}
-<!-- -->
+As highlighted in.
+
+- **Homepage** : project address
+
+- **Vcs-Browser** : Version control system browsing platform (similar to github, gitee, gitlab, etc.)
+
+- **Vcs-Git** : git repository address
+
+#### 2.1.3 debian/control files
+
+First download any source package from debian community, ubuntu community (launchpad.net) and unzip it.
+
+```Bash
+# Download the source package from the ubuntu community (launchpad.net)
+# You can also use apt-source to download source code by adding deb-src source
+# To use dget you need to install devscripts
+dget -x https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/libnftnl/1.2.3-1/libnftnl_1.2.3-1.dsc
+
+# Go to the unpacked directory
+cd libnftnl-1.2.3
 ```
-    debmake -u < upstream version number > -r < revision number > -t
 
-At this time, a new directory will be created in the same level
-directory of the source code, and its format is -
+Check the `debian/control` file for `Homepage`, `Vcs-Git`, `Vcs-Browser` and other related fields
 
-if:
+For example.
 
-The source code package is `amdgcn-tools-13.tar.gz`
-
-    # Decompression source code 
-    # The source code directory after decompression is amdgcn-tools-13 
-    tar -xaf amdgcn-tools-13.tar.gz 
-
-    # Enter the source directory, and back up the original debian directory 
-    cd amdgcn-tools-13 
-    mv debian debian-orig 
-
-    # Rebuild the debian directory 
-    debmake -u13 -rok1 -t 
-
-    # After the execution is completed, a new directory will be generated in the amdgcn-tools-13 same-level directory 
-    # <original source directory>-<upstream version number>, which is the following directory 
-    ls amdgcn-tools-13-13
-
-### 2.2 Build the debian directory directly
-
-If the upstream source code is pure source code, then just build the
-debian directory directly.
-
-    # Build the debian directory 
-    debmake -z tar.bz2
-
--   -z specifies the compressed package format of the source code
-    -   libnftnl-1.2.3.tar.bz2 is specified as -z tar.bz2
-
-    -   The default source compression format is tar.gz
--   -b If it is a perl or python source package, you can specify this
-    parameter to create more files for debmake corresponding to the
-    corresponding programming language
-
-```{=html}
-<!-- -->
+``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
 ```
-    # If it is python 
-    debmake -b ":python3" 
 
-    # perl 
-    debmake -b ":perl"
+The descriptions of the fields highlighted above are the same as in subsection 2.1.2
 
--   -t Regenerate the upstream source package (ie xxx.orig.tar.gz)
+#### 2.1.4 debian/watch files
 
-More detailed usage of debmake can be found in its man manual
+As in subsection 2.1.3, the source code needs to be downloaded first. This time, the `debian/watch` file is viewed
 
-    man debmake
+The **debian/watch** file is mainly used to record the download address of the upstream source code (this file is not required, so it may not be present in some source packages)
 
-## 3. Modify the build rules
+``Bash
+$ cat debian/watch  
+version=3
+opts=pgpsigurlmangle=s/$/.sig/ http://ftp.netfilter.org/pub/libnftnl/libnftnl-(\S+).tar.bz2
+```
 
-Mainly modify the files in the debian directory.
+The upstream source code download address recorded in this file allows you to find its corresponding project address
+
+For example.
+
+```Bash
+# The download address is usually an ftp or git release download address
+# If the download address is hosted by another platform, then you may not know the project address
+http://ftp.netfilter.org/pub/libnftnl
+
+# The above address is a good guess for the project address
+http://netfilter.org/pub/libnftnl
+```
+
+### 2.2 Getting the package version status
+
+The latest stable version list of the current project is learned by looking at the project address.
+
+This can be viewed in several ways.
+
+- debian/watch file
+
+If the package in subsection 2.1.4 has a debian/watch file, you can view the download address of the upstream package zip of the project.
+
+```!
+! The download address may contain a beta version with a name similar to xxxx-beta.tar.gz. Generally this beta version of the source code should not be selected.
+```!
+
+- git repositories
+
+If it is a git repository, you can check if its counterpart has a release git release: 1.
+
+1. If there is, then you can get a list of its releases on the git release page
+
+2. If not, see if the corresponding `branch(branch)` or `tag(tag)` has the relevant version list information
+
+
+
+# II. Building the source package
+
+Select the version of the package to be built and the download address from the first section.
+
+If there is already a project in the remote repository and you need to change the upstream version, then please check the contents of subsection 4.
+
+## 1. Download the source code and modify the source code directory format
+
+Download the source package locally and unzip it
+
+```Bash
+## Download the source code
+wget https://www.netfilter.org/pub/libnftnl/libnftnl-1.2.3.tar.bz2
+
+# Decompress
+tar -xaf libnftnl-1.2.3.tar.bz2
+```
+
+Modify the source directory to conform to the **<source_name>-<source_version>** format. For example.
+
+```Bash
+$ ls -al
+drwxr-x--@ - luzp 10 Aug 02:24 libnftnl-1.2.3
+.rw-rw----@ 395k luzp 10 Aug 02:24 libnftnl-1.2.3.tar.bz2
+```
+
+## 2. build out the debian package directory
+
+### 2.1 upstream source contains debian directory
+
+```!
+! Note: If the upstream source contains a debian directory, we need to manually rename the upstream debian directory to avoid other problems when we regenerate the debian directory
+```
+
+- Back up the original debian directory
+
+```Bash
+mv debian debian-orig
+```
+
+- Rebuild the debian directory
+
+```Bash
+debmake -u <upstream version number> -r <revision number> -t
+```
+
+This will create a new directory at the same level as the source code, in the format <name of the original source code directory> - <upstream version number>
+
+Suppose.
+
+The source tarball is `amdgcn-tools-13.tar.gz`
+
+``Bash
+# Extract the source code
+# Unzip the source code to the amdgcn-tools-13 directory
+tar -xaf amdgcn-tools-13.tar.gz
+
+# Go to the source directory and backup the original debian directory
+cd amdgcn-tools-13
+mv debian debian-orig
+
+# Rebuild the debian directory
+debmake -u13 -rok1 -t
+
+# After execution, a new directory will be created in the same level as amdgcn-tools-13
+# <original source directory>-<upstream version number>, which is the following directory
+ls amdgcn-tools-13-13
+```
+### 2.2 Building debian directories directly
+
+If the upstream source code is pure source, then just build the debian directory directly.
+
+``Bash
+### Build the debian directory
+debmake -z tar.bz2
+```
+
+-z Specify the tarball format for the source code
+  - libnftnl-1.2.3.tar.bz2 would be specified as -z tar.bz2
+
+  - The default source compression format is tar.gz
+
+-b If it is a perl or python source package, you can specify this parameter to create more files for debmake in the corresponding programming language
+
+```Bash
+# If it is python
+debmake -b ":python3"
+
+# perl
+debmake -b ":perl"
+```
+
+-t regenerate the upstream source package (i.e. xxx.orig.tar.gz)
+
+More detailed debmake usage can be found in its man page
+
+```Bash
+man debmake
+```
+
+## 3. Modify build rules
+
+The main thing is to modify the files in the debian directory.
 
 ### 3.1 control
 
-`The control `file involves two parts:
+The `control` file covers the contents of two sections.
 
-#### 3.1.1 Source package part
+#### 3.1.1 Source package section
 
-Describe the brief information of the current source package, and the
-compilation dependencies for building the source package, etc.
+A brief description of the current source package, and the compilation dependencies for building it
 
-There are several fields to note:
+There are several fields that need to be noted.
 
--   **Section**
+- **Section** 
 
-Describes the type of package and is used for categorization of
-packages. For example, `mysql-8 `should belong to `database`
+Describes the type of package, and is used to classify the package. For example, `mysql-8` should belong to `database`.
 
-The optional contents are:
+The options are.
 
-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
+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**
-    -   Priority of packages
+- **Priority**
+  - Priority of the package
 
-    -   required Packages required by the system
+  - required System required packages
+  - important Important packages, packages that are not required for the system, but preferably pre-installed on the system
+  - standard Standard Relatively independent packages
+  - optional This is the default priority option, which should be used unless the package is a system-required package
 
-    -   important Important software packages, non-essential packages
-        for the system, but hopefully pre-installed in the system
+- **Maintainer** 
+It needs to be written as the current openkylin sig group responsible for the package, e.g. `packaging sig` group is written as `Openkylin Developers <packaging@lists.openkylin.top>`
 
-    -   standard Standard relatively independent software package
+- **Vcs-Browser**:
 
-    -   optional This is the default priority option and should be used
-        unless the package is required by the system
--   **Maintainer**
+Write it to the corresponding gitee repository address, e.g. https://gitee.com/openkylin/autoconf
 
-It needs to be written as the current openkylin responsible for the sig
-group of the software package, such as `the packaging sig `group written
-as `Openkylin Developers <packaging@lists.openkylin.top>`
+- **Vcs-Git**.
 
--   **Vcs-Browser** :
+Write to the corresponding gitee repository git address, e.g. https://gitee.com/openkylin/autoconf.git
 
-Write it as the corresponding gitee warehouse address, such as
-https://gitee.com/openkylin/autoconf
+- **Build-Depends and **
 
--   **Vcs-Git**
+Build dependencies needed to compile architecture-related code
 
-Write it as the corresponding gitee warehouse git address, such as
-https://gitee.com/openkylin/autoconf.git
+- **Build-Depends-Indep**
 
--   **Build-Depends and**
+Compilation dependencies required to compile architecture-independent code
 
-Compilation dependencies required to compile architecture-dependent code
+For **Build-Depends** and **Build-Depends-Indep** you can find the relevant compilation dependencies from the project address.
 
--   **Build-Depends-Indep**
+---
+**Note:** If the control file references rules from another OS distribution, you need to remove or replace the version number rules in the other OS version, for example.
 
-Compilation dependencies required to compile architecture-independent
-code
+```
+Build-Depends: 
+  pkg1 (>= 1.0.0-0ubuntu1), 
+  pkg1 (< 1.2.0-1debian2),
+  pkg2 (> 1.0.0.build),
+  pkg3 (> 2.0ubuntu19)
+```
 
-For **Build-Depends** and **Build-Depends-Indep,** you can find whether
-there are related compilation dependency instructions from the project
-address.
+First of all, it should be clear that for quilt format version numbers generally have "-" in the format `<upstream_version>-<revision>`, while native format source packages generally do not contain "-"
 
-**Note:** If the control file refers to the rules of other OS releases,
-you need to remove or replace the version number rules in other OS
-versions, for example:
+The modification process can be done in two steps
 
-    Build-Depends: 
-    pkg1 (>= 1.0.0-0ubuntu1), 
-    pkg1 (< 1.2.0-1debian2), 
-    pkg2 (> 1.0.0.build), 
-    pkg3 (> 2.0ubuntu19)
+**Step 1:**
 
-First of all, it needs to be clear that the version number in quilt
-format generally has \"-\", the format is
-`<upstream_version>-<revision> `, and the source package in native
-format generally does not contain \"-\"
+For quilt-formatted versions, the version numbers 1.0.0-0ubuntu1 and 1.2.0-1debian2 in pkg1 contain the version number of the specific OS distribution, so they should be modified. It also becomes.
 
-The modification process can be carried out in two steps
+```
+pkg1 (>= 1.0.0), 
+pkg1 (< 1.2.0),
+```
 
-**first step:**
+For version numbers in native format, you first need to determine its upstream version, for pkg2 and pkg3.
 
-For versions in quilt format, the version numbers 1.0.0-0ubuntu1 and
-1.2.0-1debian2 in pkg1 contain version numbers for specific OS
-distributions, so modify them. It also becomes:
+(1) Try to find the 1.0.0 version of pkg2, if you can find it, then 1.0.0 is the upstream version, and its compilation dependency should be changed to: pkg2 (> 1.0.0); same as pkg3
 
-    pkg1 (>= 1.0.0), 
-    pkg1 (< 1.2.0),
+(2) If the upstream version of pkg2 cannot be found, and the current version number does not contain the name of other OS distributions, then it can be kept (because the source-package tool is used to repackage the source code, its upstream version number is also the current version number); but for pkg3, if pkg3 is OS self-developed (its source code name usually However, for pkg3, if pkg3 is OS developed (its source code name also contains OS name, e.g. ubuntu-keyring), then this package can be renamed and maintained by openkylin, with the corresponding source code name changed to openkylin-keyring and the version number redefined, e.g. 1:1.0.0; if it is not OS developed package, it is better for us to redefine the version number and maintain it according to If it is not an OS self-developed package, it is better that we also re-define the version number and maintain it according to our own version number, which can be discussed internally, e.g. 1:1.0.0 is also specified here.** Note that here, it is better to use the version number in : format, which indicates that the version number with : is always higher than the version number without. **
 
-For the version number in native format, you first need to determine its
-upstream version, for pkg2 and pkg3:
+Then, for pkg2, pkg3, it is modified as follows
 
-\(1\) Try to find the 1.0.0 version of pkg2. If you can find it, then
-1.0.0 is the upstream version, and its compilation dependency is changed
-to: pkg2 (\> 1.0.0); similarly to pkg3
+```
+pkg2 (> 1.0.0.build),
+pkg3 (> 1:1.0.0)
+```
+**Step 2 (native format is not handled):**
 
-\(2\) If the upstream version of pkg2 cannot be found, and the current
-version number does not contain other OS distribution names, then it can
-be kept (because the source code is repackaged with the source-package
-tool, the upstream version number is also the current version number);
-But for pkg3, if pkg3 is self-developed by the OS (its source code name
-generally also includes the OS name, such as ubuntu-keyring), then this
-package can be renamed at this time, re-maintained by openkylin, and the
-corresponding source code name is changed to openkylin-keyring , the
-version number is also reformulated, for example, it can be formulated
-as 1:1.0.0; if it is not an OS self-developed package, it is best that
-we also reformulate the version number, maintain it according to our own
-version number, and discuss it internally, for example, specify here is
-1:1.0.0. **Note here, it is best to use the version number in the :
-format, which indicates that the version number with: will always be
-higher than the version number without it.**
+The second step is to improve on the first step. In general we need to clarify the content of the revisions in other OS distributions that follow the - horizontal line.
 
-Then, for pkg2, pkg3, its modification is:
+For <upstream_version>-<revision>, generally each revision is a fix for a bug, security vulnerability, etc. For ubuntu, each revision is made up of several patches.
 
-    pkg2 (> 1.0.0.build), 
-    pkg3 (> 1:1.0.0)
+So for pkg1 (>= 1.0.0-0ubuntu1), it is explicitly stated that it can only be used after revision 0ubuntu1, which means that using pkg1 version 1.0.0 is risky, and the most immediate phenomenon is that the compilation does not pass.
 
-**The second step (native format does not need to be processed):**
+Therefore, it is necessary to combine our actual pkg1 version situation to.
 
-The second step is to improve on the basis of the first step. In
-general, we need to clarify the content of the revision after the - dash
-in other OS distributions.
+(1) If pkg1 exists in the repository, its version is 1.0.0-ok1. In order to ensure that the above compilation passes, it is necessary to integrate the patch in ubuntu's 1.0.0-0ubuntu1. If the relevant patch is already integrated, then the compilation dependency becomes.
 
-For -, generally speaking, each revision fixes a certain bug, security
-vulnerability, etc. For ubuntu, each revision consists of several
-patches.
+```
+pkg1 (>= 1.0.0-ok1), 
+pkg1 (< 1.2.0),
+```
 
-Therefore, for pkg1 (\>= 1.0.0-0ubuntu1), it is clearly stipulated that
-it can only be used after the 0ubuntu1 revision, which means that there
-is a risk in using pkg1 version 1.0.0. The most direct phenomenon is
-that the compilation fails.
+After the patch integration, the pkg1 version in the repository becomes 1.0.0-ok2. Then, where the dependencies are compiled, it becomes
 
-Therefore, this needs to be combined with our actual pkg1 version:
+```
+pkg1 (>= 1.0.0-ok2), 
+pkg1 (< 1.2.0),
+```
 
-\(1\) If pkg1 exists in the warehouse, its version is 1.0.0-ok1. In
-order to ensure that the above compilation can pass, the patch in ubuntu
-1.0.0-0ubuntu1 needs to be integrated. If the relevant patch has been
-integrated, then the compilation dependency becomes:
+(2) If pkg1 does not exist in the repository, then when we select the build independently for the first time, it is better to select the version between 1.0.0~1.2.0 to ensure that the compiled dependencies of each dependency package can be met.
 
-    pkg1 (>= 1.0.0-ok1), 
-    pkg1 (< 1.2.0),
+The above is based on compilation dependencies. If the version number is also specified in the installation dependency field of the binary package, then it is handled in the same way as above.
 
-After the patch is integrated, the pkg1 version in the warehouse becomes
-1.0.0-ok2. Then where the compile dependency becomes:
+#### 3.1.2 Binary package section
 
-    pkg1 (>= 1.0.0-ok2), 
-    pkg1 (< 1.2.0),
+Describes which binary package programs the current source package can be divided into.
 
-\(2\) If pkg1 does not exist in the warehouse, then when we choose and
-build independently for the first time, it is best to choose a version
-between 1.0.0\~1.2.0 to ensure that the compilation dependencies of each
-dependent package can be satisfied.
+Common types of subpackages are
 
-The above are all processed based on compilation dependencies.
-Similarly, if the version number is also specified in the installation
-dependency field of the binary package, the processing method is the
-same as above.
+- lib
 
-#### 3.1.2 Binary package part
+shared library, whose binary package name is usually `lib-xxx`.
 
-Describes which binary packages the current source package can be
-divided into.
+- dev
 
-Common types of subcontracting are:
+Shared library headers and related development files, usually named `lib-xxx-dev`
 
--   lib
+- doc
 
-Shared library, its binary package name is generally `lib-xxx`
+Documentation of a package
 
--   dev
+If the documentation corresponds to the documentation of an executable, the binary package name is usually `xxx-doc`.
 
-Shared library header files and related development files, the binary
-package name is generally `lib-xxx-dev`
+If the documentation is for a development library, the binary package name is usually `lib-xxx-doc`.
 
--   doc
+- bin
 
-Documentation for the package
+The binary package name is usually the name of the corresponding binary program of a package, such as the binary program of a compiled language (e.g., c/c++) and the executable program of an interpreted programming language (e.g., python, perl)
 
-If its document corresponds to the document of an executable program,
-its binary package name is generally `xxx-doc`
+This sub-package can be used in combination with ``debmake`` when building the ``debian` package directory, e.g.
 
-If its document is a document of a development library, its binary
-package name is generally `lib-xxx-doc`
+```Bash
+# The package name is foo, which provides the binary and the documentation for the binary
+debmake -b "foo:bin,foo-doc:doc"
 
--   bin
-
-Binary programs of software packages, such as binary programs of
-compiled languages (such as c/c++) and executable programs of
-interpreted programming languages (such as python and perl), the binary
-package name is generally the name of the corresponding binary program
-
-This subpackage can be used together with `debmake `when building the
-`debian `packaging directory, such as:
-
-    # The package name is foo, which provides binary programs and binary program documentation 
-    debmake -b "foo:bin,foo-doc:doc" 
-
-    # The name of the package is libfoo, which is a development library source code, which provides the development library and development library documentation 
-    debmake -b "libfoo:lib,libfoo-doc:doc" 
-
-    # After execution, each binary package information template will be automatically written into the debian/control file
+# The package name is libfoo, which is the source code for a development library that provides documentation for the development library and the development library
+debmake -b "libfoo:lib,libfoo-doc:doc"
 
+# After execution, each binary package information template will be automatically written to debian/control file
+```
 ### 3.2 rules
 
-Compilation and build rules for packages
+Package compilation and build rules
 
 ### 3.3 changelog
 
-Modify the version number of the software package in the format:-
+Modify the package version number in the format: <upstream_version>-<revisions>
 
-Generally speaking, for the openkylin community, use `ok1 `as the first
-revisions, such as:
+In general, for the openkylin community, use `ok1` for the first revisions, e.g.
 
-    autoconf ( 2.71-ok1 ) yangtze ; urgency = low
+```Bash
+autoconf (2.71-ok1) yangtze; urgency=low
 
-      * Build for openKylin.
+  * Build for openKylin.
 
-     -- Lu zhiping < luzhiping@kylinos.cn > Fri, 26 Aug 2022 15:25:09 +0800
+ -- Lu zhiping <luzhiping@kylinos.cn> Fri, 26 Aug 2022 15:25:09 +0800
+```
 
 ### 3.4 source/format
 
-The format of the source package must be set to `quilt `format
+The source package must be formatted as `quilt` format
 
-    echo "3.0 (quilt)" > debian/source/format
-    echo "3.0 (quilt)" > debian/source/format
+```Bash
+echo "3.0 (quilt)" > debian/source/format
+```
 
-### 3.5 Other documents
+```Bash
+echo "3.0 (quilt)" > debian/source/format
+```
+
+### 3.5 Other files
 
 xxx.install
 
@@ -570,250 +474,225 @@ xxx.symbols
 
 xxx.manpages
 
-### 3.6 Apply patches for other OS distributions
+### 3.6 Applying patches from other OS distributions
 
-If other OS distributions have patches for this package, then we need to
-analyze and consider whether to apply their patches.
+If other OS distributions have patches for the package, then we need to analyze and consider whether to apply their patches.
 
-You can first consider whether to apply patches of other OS releases
-from the following aspects:
+You can start by considering whether to apply patches from other OS distributions in the following ways.
 
--   What does the patch fix? Is the reason why the patch is not absorbed
-    by the upstream community, is it an irrelevant patch?
+- What is fixed by the patch? Is it an irrelevant patch that has not been absorbed by the upstream community?
 
--   Is it a patch only available in the old version, has the new version
-    been integrated?
+- Is it a patch that was only available in a previous, older release and has it been integrated in a new release?
 
--   Is it a major bug fix?
+- Is it a major vulnerability fix patch?
 
--   Is the patch required only for a specific OS distribution?
+- Is it a patch that is only required for a specific OS distribution?
 
--   If the patch is not applied, is there any compilation problem, and
-    is there any problem with the installation?
+- If the patch is not applied is there a compilation problem and is there a problem with the installation?
 
-```{=html}
-<!-- -->
 ```
-    Moreover, it is best to apply the patches of the upstream community after building the git repository, so that the information of the upstream community patches can be retained in the git commit
+Also, it's best to apply patches from the upstream community after building out the git repository, so that the information from the upstream community patches can be retained in the git commit
+```
 
-The following are the steps to apply patch after building the git
-repository in Chapter 5:
+Here are the steps for applying patches after building out a git repository in Section 5.
 
-If you need to apply patches from the upstream community, it is best to
-keep the content and author information of their patch information. You
-can directly apply the patch of the upstream community through the git
-tool:
+If you need to apply patches from upstream communities, it is best to keep the content and author information of their patches. You can apply patches from upstream communities directly through the git tool.
 
--   git am apply patch
+- git am apply patch
+The git am application patch will automatically keep the patch information
 
-The git am application patch will automatically retain the patch
-information
+``Bash
+git am xxxx.patch
+```
 
-    git am xxxx.patch
+- git apply applies patch
 
--   git apply apply patch
+But some patches don't have the exact same information format as git am, so you can use git apply to import the patches and then commit to add the patch information
 
-However, the information format of some patches is not fully applicable
-to git am, then you can use git apply to import the patch, and then
-commit to add patch information
+```Bash
+# import patch information
+git apply xxx.patch
 
-    # Import patch information 
-    git apply xxx.patch 
+# Add changes
+git add .
 
-    # Add changes 
-    git add . 
+# Fill in the edit box with information about the patch, such as
+# the author of the patch, the content of the patch, etc.
+git commit
+git commit .
 
-    # Fill in the relevant information of the patch in the edit box, such as 
-    # the author of the patch, the content of the patch, etc. 
-    git commit
+After importing a patch, if you want to compile and test the newly imported patch, you can use the gbp tool to generate the new source code (new dsc file)
 
-After importing the patch, if you want to compile and test the content
-of the newly imported patch, you can use the gbp tool to generate a new
-source code (new dsc file)
+```Bash
+# Modify changelog to add a new version number
+vim debian/changelog
 
-    # Modify the changelog to add a new version number 
-    vim debian/changelog 
+# Compile the source code, which will generate a new dsc file
+gbp buildpackage -S -sa -nc --git-prisine-tar --git-ignore-branch
+```
 
-    # Compile the source code and generate a new dsc file 
-    gbp buildpackage -S -sa -nc --git-prisine-tar --git-ignore-branch
+## 4. Importing upstream source code
 
-## 4. Import upstream source code
+If the remote repository already has a project, you need to change the upstream version.
 
-If there is an existing project in the remote warehouse, the upstream
-version needs to be changed.
+(1) Download the source tarball from the upstream community
 
-\(1\) Download the source code package from the upstream community
+(2) Re-compress the source tarball to match the ``<package-name>_<pacakge-version>.orig.tar.[gz|xz|bz2]` format
 
-\(2\) Recompress the source code package to conform to
-`the <package-name>_<pacakge-version>.orig.tar.[gz|xz|bz2] `format
+```Bash
+# For example.
+# The source tarball obtained from the upstream source community is requests-2.27.1.tar.gz
+# First extract the source code
+tar -xaf requests-2.27.1.tar.gz
 
-    #For example: 
-    # The source code compression package obtained from the upstream source code community is requests-2.27.1.tar.gz 
-    # First decompress the source code 
-    tar -xaf requests-2.27.1.tar.gz 
+# Change the source directory to <package-name>-<package-version>
+# If the source tarball from the upstream community is extracted from the requests directory
+mv requests requests-2.27.1
 
-    # Modify the source directory to <package-name>-<package-version> 
-    # If the directory decompressed from the source compression package of the upstream community is requests 
-    mv requests requests-2.27.1 
+# Recompress to match <package-name>_<pacakge-version>.orig.tar.[gz|xz|bz2] 
+tar -czf requests-2.27.1 requests-2.27.1.orig.tar.gz
+```
 
-    # Recompress to conform to <package-name>_<pacakge-version>.orig.tar.[gz|xz|bz2] 
-    tar -czf requests-2.27.1 requests-2.27.1.orig.tar.gz
+(3) Clone the gitee remote repository source code to local, enter the source code directory
 
-\(3\) Clone the source code of the gitee remote warehouse to the local,
-and enter the source code directory
+```Bash
+# Clone the remote repository
+git clone git@gitee.com:openkylin/requests.git
 
-    # Clone the remote warehouse 
-    git clone git@gitee.com:openkylin/requests.git 
+# Enter the source directory
+cd requests
+```
+(4) Changing upstream source code
 
-    # Enter the source directory 
-    cd requests
+Refer to chapter 6 of the [openKylin source package git workflow](openKylin source package git workflow.md) section "Updating upstream versions".
 
-\(4\) Change the upstream source code
+- a. Import the upstream version (the zip generated in step 2)
 
-Refer to Chapter 6 \"Update the upstream version\" of [the git workflow
-of the openKylin source package](openKylin源码包git工作流.md)
+- ``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
+    ```
 
--   a.  Import the upstream upstream version (compressed package
-        generated in the second step)
+- b. Filtering old patches (in conjunction with [openKylin source package git workflow] (openKylin source package git workflow.md) subsection 6.3.3)
 
--   -   `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`
+- If the patch is an R&D patch, then you need to confirm with the relevant R&D that the patch is still required in the new upstream source code
+  - If the patch is a patch from another OS distribution, then confirm with the OS distribution that the patch is still required in the latest version of the source code
 
--   b.  Filter old version patches (combined with [openKylin source
-        package git workflow](openKylin源码包git工作流.md) section
-        6.3.3)
+- c. Introducing patches from other OS distributions
 
--   -   If the patch is a developed patch, you need to confirm with the
-        relevant research and development whether the patch is still
-        needed in the new upstream source code
-    -   If the patch is a patch of another OS distribution, then it
-        needs to be combined with the latest source code of the OS
-        distribution to confirm whether the patch is still needed
+- You can refer to subsection 3.6, "Applying patches from other OS distributions".
 
--   c.  Introduce patches for other OS distributions
+  - Use git am or git apply or other methods to import patches from other OS distributions
 
--   -   You can refer to Section 3.6 \"Applying Patches for Other OS
-        Releases\".
+- d. Modify other build files in the debian directory
 
-    -   Use git am or git apply or other methods to import patches from
-        other OS distributions
+- debian/control
+  - debian/changelog needs to retain the original changelog information
+  - debian/rules
+  - deiban/other files
 
--   d.  Modify other compiled and built files in the debian directory
-
--   -   debian/control
-    -   debian/changelog needs to keep the original changelog
-        information
-    -   debian/rules
-    -   deiban/other files
-
-After the modification is completed, you can compile and test locally
-according to Section 5, and then push it to the remote warehouse after
-the test has no problems.
+After the changes are done, you can follow section 5 and test the build locally first, then push it to the remote repository after the test is done.
 
 ## 5. Compile the source package
 
-After completing the construction rules of the debian directory, compile
-a round of source packages based on this. dsc file will be generated
+After completing the build rules for the debian directory, first compile a round of source packages based on this. The dsc file will be generated
 
-    # Cut to the development branch 
-    git checkout openkylin/yangtze # Execute 
-    dpkg-source in the source code directory
-     -b .
+``Bash
+## Switch to the development branch
+git checkout openkylin/yangtze
+# Execute in the source directory
+dpkg-source -b .
+```
 
-# 3. Compile
 
-After building the source code package according to the content of the
-previous chapter, compile it.
 
-You can download an openkylin chroot environment and compile and debug
-in the chroot environment.
+# III. Compile
 
-chroot for x86:
-http://files.build.openkylin.top/51159/chroot-openkylin-yangtze-amd64.tar.gz
+After building the source package according to the previous section, compile it.
 
-chroot of riscv:
-http://files.build.openkylin.top/51197/chroot-openkylin-yangtze-riscv64.tar.gz
+You can download a chroot environment of openkylin and compile and debug in the chroot environment.
 
-At this stage, the packaging and building rules in the debian packaging
-directory will be continuously modified and optimized until a complete
-binary package that can be installed is packaged.
+The chroot for x86: http://files.build.openkylin.top/51159/chroot-openkylin-yangtze-amd64.tar.gz
 
-# 4. Installation test
+riscv chroot: http://files.build.openkylin.top/51197/chroot-openkylin-yangtze-riscv64.tar.gz
 
-Simply test whether the compiled binary program can be installed,
-whether the system is normal after installation, etc.
+At this stage, the package build rules in the debian package directory will be continuously modified and optimized until a complete installable binary package is packaged.
 
-# 5. Build a git repository
 
-## 1. Create a gitee warehouse
 
-Fork openkylin\'s community repository
+# IV. Installation Testing
 
-    # After fork to the personal warehouse, clone the personal warehouse to the local 
-    git clone git@gitee.com: < username > /community.git 
+Simply test whether the compiled binary is installable and whether the system works properly after installation, etc.
 
-    # Then add the source code package name in the corresponding sig group sig.yaml file 
-    # For example, add a new one for packaging sig Software package, source-name needs to write the actual package name 
-    echo "-<source-name>" >> sig/packaging/sig.yaml 
+## V. Building a git repository
 
-    # Then submit the changes and push them to the personal warehouse 
-    git add sig/packaging/sig.yaml 
-    git commit -m "Add xxx package" 
-    git push origin master
+## 1. create gitee repository
 
-Create a PR on the gitee web page, and then review it by the community
-project leader. After the review is passed, the CI platform will
-automatically create the corresponding git warehouse
+fork openkylin's community repository
+
+``Bash
+# After fork to your personal repository, clone your personal repository to local
+git clone git@gitee.com:<username>/community.git
+
+# Then add the source package name to the corresponding sig group sig.yaml file
+# For example, to add a package to the packaging sig, the source-name should be the actual package name
+echo "- <source-name>" >> sig/packaging/sig.yaml
+
+# Then commit the changes and push them to your personal repository
+git add sig/packaging/sig.yaml
+git commit -m "Add xxx package"
+git push origin master
+```
+
+Create a PR on the gitee web side, and then have it reviewed by the community project leader. After the review, the CI platform will automatically create the corresponding git repository
 
 ## 2. Build the git repository
 
-Build the git repository for the source package built in the second
-chapter.
+Build the git repository for the source package built in chapter 2.
 
--   download tool
+- Download the tool
 
-Download the tool and install related dependencies according to the
-usage method of the [source-packaging
-tool](https://gitee.com/openkylin/packaging-tools#源码反向构建工具-source-packing)
+Follow the [source-packaging](https://gitee.com/openkylin/packaging-tools#源码反向构建工具-source-packing) tool instructions to download the tools and install the dependencies.
 
--   build git repository
+- Build the git repository
 
-```{=html}
-<!-- -->
+```Bash
+. /source-packing import-to-git --dsc-file sqlite3_3.31.1-ok1.dsc --packaging-branch openkylin/yangtze
 ```
-    ./source-packing import-to-git --dsc-file sqlite3_3.31.1-ok1.dsc --packaging-branch openkylin/yangtze
 
-For more detailed git workflow, please refer to [the openKylin source
-package git workflow](openKylin源码包git工作流.md)
+More detailed git workflow can be found in [openKylin source package git workflow](openKylin source package git workflow.md) 
 
-## 3. Associate the remote warehouse and push it to gitee
+## 3. Associating remote repositories and pushing to gitee
 
-It is necessary to push the package to the gitee warehouse after the
-third chapter is compiled and the fourth chapter is installed and
-tested.
+You need the package to be compiled in chapter 3 and installed and tested in chapter 4 before pushing it to the gitee repository
 
-    # Enter the source code warehouse built in the second step 
-    cd sqlite3 
-    # Associate the remote warehouse and push it to the remote warehouse 
-    git remote add origin git@gitee.com:openkylin/sqlte3.git 
-    git push --all && git push --tags
-
-# 6. Other content
-
-1.  A brief description of gitee\'s ci process:
-
-```{=html}
-<!-- -->
+```Bash
+# Go to the source code repository built in step 2
+cd sqlite3
+# Associate the remote repository and push to it
+git remote add origin git@gitee.com:openkylin/sqlte3.git
+git push --all && git push --tags
 ```
-    1. The first push of the software package: 
-    The maintainer pushes the package to the gitee warehouse for the first time. At this time, the ci platform will package it and send it to the okbs compilation platform for compilation. The current compilation address is (https:// build.openkylin.top/~cibot/+archive/openkylin/citest/+packages) 
 
-    2. Subsequent modification contributions: 
-    developers need to fork the warehouse to their personal warehouse, and then make development and modification on the personal warehouse, after the source code modification is completed Modify the changelog to add a new version number, and then submit the PR to the original warehouse. 
 
-    The maintainer reviews the PR. After the PR review is passed, the CI platform will automatically package the current PR and send it to the OKBS compilation platform for compilation. The compilation result will be added to the corresponding PR in the form of comments. The maintainer will use the compilation result and the access control of the CI platform Check the results to consider accepting the PR
 
-2.  The source address of each release version, taking gvfs as an
-    example:
+# VI. Other content
+
+1. A brief description of gitee's ci process.
+
+```Bash
+1. package first push.
+maintainer first pushes the package to the gitee repository by way of push, at which point the ci platform sends its package to the okbs compilation platform for compilation, and the current compilation address is (https://build.openkylin.top/~cibot/+archive/openkylin/ citest/+packages)
+
+2. Subsequent modification contributions.
+The developer needs to fork the repository to the personal repository, then develop changes on the personal repository, and then modify the changelog to add the version number after the source code is modified, and then submit the PR to the original repository.
+
+maintainer review PR, PR review passed, CI platform automatically package the current PR sent to OKBS compilation platform for compilation, the compilation results will be added to the corresponding PR in the form of comments, maintainer according to the compilation results and CI platform gate check results to consider whether to accept the PR
+```
+
+2. The source address of each distribution, using gvfs as an example.
 
 Debian 11: https://tracker.debian.org/pkg/gvfs
 
@@ -825,4 +704,4 @@ Arch: https://archlinux.org/packages/extra/x86_64/gvfs/
 
 Deepin: https://ftp.sjtu.edu.cn/deepin/pool/
 
-openEuler: https://gitee.com/src-openeuler/gvfs
+openEuler: https://gitee.com/src-openeuler/gvfs
\ No newline at end of file