linx/documents
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

[Bug #2480] applications.git库介绍

Browse Source 
modified:   README.md
	modified:   intro-applications-repository.md

Signed-off-by: Yingchun Zhu <yczhu@linx-info.com>
This commit is contained in:
Yingchun Zhu
2015-09-18 13:06:39 +08:00
parent 5f6acb4a01
commit b6a569f722
2 changed files with 57 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
README.md
View File

@@ -9,3 +9,5 @@
## [操作系统版本以及对应光盘版本说明](OS-version-node.md) ##
## [linx6.0.42.41新版发布实现说明](release_stable.md) ##
## [applications.git库介绍](intro-applications-repository.md) ##

85
intro-applications-repository.md
View File

@@ -1,26 +1,31 @@
# applications介绍
# applications.git库介绍
本文档主要用来介绍applications目录的结构，各个子目录，以及其中包含的各种文件的用途。预期达到的效果是，让首次将applications.git库克隆到本地的用户能够通过阅读此文档，对applications目录的内容有个总体的了解。
咱们知道，applications.git是gitlab上的一个git库，具体存放位置[点击这里查看](http://gitlab.rd.in.linx/linx6.0.42/applications.git)。当咱们通过git clone这条命令，将这个版本库克隆到本地机器上的时候，同时会创建出此git库的工作区，在本地机器上的表现形式就是创建了一个applications目录，本文档的介绍也就是从这里开始的。
:zap:注意：在这篇文档中，我在刻意强调git工作区（git workspace)和git库（git repository)的区别，就我目前的理解，我认为在哪个目录下初始化了git（git init），哪里就是git工作区；而git库是在工作区中的隐藏目录.git。
本文档主要用来介绍applications目录的结构，各个子目录，以及其中包含的各种文件的用途。预期达到的效果是，让首次将applications.git库克隆到本地的用户能够通过阅读此文档，对applications目录的结构和内容有个总体的了解。
我们知道，applications.git是gitlab上的一个git库，具体存放位置[点击这里查看](http://gitlab.rd.in.linx/linx6.0.42/applications.git)。通过
```
git clone git@gitlab.rd.in.linx:linx6.0.42/applications.git
```
这条命令，将这个版本库克隆到本地机器上的时候，就会在本地创建出此git库的工作区，在本地机器上的表现形式就是创建了一个applications目录，本文档的介绍也就是从这里开始的。
:zap:注意：在这篇文档中，我在刻意强调git工作区（git workspace)和git库（git repository)的区别，就我目前的理解，我认为在哪个目录下初始化了git（git init），哪里就是git工作区；而git库是在工作区中的隐藏目录.git，文档的编写基于这样的概念展开。
## 1.applications的用途
GNU/Linux操作系统（GNU/Linux OS）本身是由linux内核和特定GNU应用软件组成的，所以，一个特定版本的OS对应着很多软件包，我们可以称之为软件仓库。怎么样才能有效地管理这个软件仓库，对GNU/Linux OS的维护者而言是非常值得研究的问题。很明显，这会在很大程度上降低管理大量软件包的繁琐程度，给OS维护人员带来方便，提高维护人员的工作效率。
因为在管理rocky6.0.42.41这个OS的软件包时选择了git这个工具，远程git库的管理用的是gitlab，所以才有了克隆applications.git库，然后在本地自动创建了applications工作区的过程。
所以说，本地的applications目录，就是维护rocky6.0.42.41的工作区。在它的子目录packages下存放的是rocky6.0.42.41用到的所有软件包，因此维护rocky6.0.42.41的工作基本上都是在这个里进行的，升级或者更换了packages目录下的软件包，就等于是升级或者更换了rocky6.0.42.41的软件包，至于为什么会这样，可以阅读另一篇文档[点击这里查看](http://gitlab.rd.in.linx/linx6.0.42/documents/blob/master/workflow.md)，或许有一定的帮助。
在applications目录下还有另外一个子目录build，这个是在rocky6.0.42.41以前的OS生成镜像文件时用到的目录，现在已经不再使用了，所以可以不用管它。下面将会对applications的packages子目录进行介绍。
GNU/Linux操作系统（GNU/Linux OS）本身是由linux内核和特定GNU应用软件组成的，所以，一个特定版本的OS对应着很多软件包，我们可以称之为软件仓库。怎么样才能有效地管理这个软件仓库，对GNU/Linux OS的维护者而言是非常值得研究的问题，解决好了这个问题，会在很大程度上降低管理大量软件包的繁琐程度，给OS维护人员带来方便，提高维护人员的工作效率。
管理rocky6.0.42.41这个OS的软件仓库时用的是git这版本控制个工具，远程git库的管理用的是gitlab，这样的一个基础架构，决定了我们需要克隆applications.git库，需要了解applications工作区。
所以说，本地的applications目录，就是维护rocky6.0.42.41的工作区。在它的子目录packages下存放的是rocky6.0.42.41用到的所有软件包，维护rocky6.0.42.41的工作基本上都是在这个目录里进行的，升级或者更换了packages目录下的软件包，就等于是升级或者更换了rocky6.0.42.41的软件包，至于为什么会这样，可以阅读另一篇文档[点击这里查看](http://gitlab.rd.in.linx/linx6.0.42/documents/blob/master/workflow.md)，或许有一定的帮助。
在applications目录下还有另外一个子目录build，这个是在rocky6.0.42.41以前的OS生成镜像文件时用到的目录，现在已经不再使用了，所以可以不用管它。下面将会对本地applications目录的结构和内容进行介绍。
## 2.applications的组织结构
将git库克隆到本地机器后，会创建出维护rocky6.0.42.41的工作区，即applications目录，所以这里就以介绍这个目录里的内容为中心展开，包括各个目录，子目录，目录中的文件，以及它们的作用，但是由于目前已经不再使用build子目录中的内容，所以不再介绍这个目录。
将git库克隆到本地机器后，会创建出维护rocky6.0.42.41的工作区，即applications目录，所以这里就以介绍这个目录里的内容为中心展开，包括各个目录，子目录，目录中的文件，以及它们的作用，由于目前已经不再使用build子目录中的内容，所以这里不再介绍这个目录。
### 2.1 applications的目录树结构
下面是通过“tree applications”命令显示出来的applications目录的结构，其中省略了大量的子目录。当你用ls查看一下你本地的工作区applications，你会发现工作区的目录层级结构是非常简单的，很容易看清楚。所以，省略的这些子目录对于本文档的预期目标是无关紧要的。尽管如此，下面还是列出了一些子目录，这样做的目的仅仅是为了说明这些子目录下的内容。这几个目录具有一定的代表性，包含了所有子目录中将会出现的大多数文件。
在applications目录的父目录里通过命令
```
tree applications
```
可以显示出applications目录的树型结构。下图中省略了大量的子目录，因为浏览工作区applications时你会发现工作区的目录层级结构是非常简单的，很容易看清楚。所以，省略的这些子目录对于本文档的预期目标是无关紧要的。这里列出几个具有代表性的目录，其中包含了所有子目录中将会出现的文件。
```
applications/
@@ -91,22 +96,22 @@ applications/
├── y
└── z
```
当你浏览了你本地机器上的applications工作区之后，你会发现，所有子目录下的文件无外乎就这么几种：源码包、Pkgfile文件，这是每一个软件包目录下必有的；post_mk.sh文件、post_add.sh文件、补丁文件，这几个文件，你会发现，有些软件包目录下有，有些软件包目录下没有。下面分别进行介绍。
每个源码包目录下的文件：
* 必有的文件：源码包、Pkgfile文件；
* 可能会有的文件：post_mk.sh、post_add.sh、\*.patch、\*.conf，这几个文件，有些软件包目录下有，有些软件包目录下没有；
* 隐藏文件：\.footprint*、md5sum。
下面分别进行介绍。
### 2.2 分述各个目录和文件的作用
浏览applications工作区，首先看到两个目录：build和packages。
* build是rocky6.0.42.41以前的版本在生成镜像文件时用到的目录，现在已经不再使用，所以不用管这个目录。
* packages目录下存放着构建rocky6.0.42.41用到的所有源码包。
浏览packages目录，可以看到它有`以26个英文字母命名的子目录`。再浏览这些子目录（任意选中一个进行浏览），发现这个目录下依然是一些目录，不过`这里的目录名全是以一些软件包的名字命名的，并且这些软件包名的首字母就是它所在的目录`。继续往下，才发现了源码包和Pkgfile文件，或许还有其他的一些文件。
看到这里，想必你已经理解了，这里也是运用了计算机技术中大量使用的“分层技术”，通过不断划分层次来对源代码包和与其相关的文件进行归类。不管你认不认同这种处理方法，它已经这样做了。不过，在我看来划分层次在这里还是起到了非常好的效果，至少找一个软件包非常容易了。
再看软件包名目录下的内容，因为每个软件包名目录下的内容都大同小异，所以这里咱们只会整体上介绍文件包名目录下的文件种类，不会也不可能介绍每一个软件包名目录。
* build是rocky6.0.42.41以前的版本在生成镜像文件时会用到的目录，现在已经不再使用，所以不用管这个目录。
* packages目录下存放着构建rocky6.0.42.41用到的所有源码包。
* packages的子目录`以26个英文字母`命名；
* 每个字母目录下存放的是所有`包名以这个字母开头`的源码包。
再源码包目录下的内容，因为每个源码包目录下的内容都大同小异，所以这里只会整体上介绍源码包目录下的文件种类，不会也不可能介绍每一个源码包目录下的内容。
* 源码包：从网络上下载的源代码包；
* Pkgfile：编译rocky6.0.42.41上的二进制包时用到的文件，关于Pkgfile文件的介绍[点击这里查看](http://gitlab.rd.in.linx/linx6.0.42/documents/blob/master/Pkgfile-yczhu.md)。
* Pkgfile：编译rocky6.0.42.41的二进制包时用到的文件，关于Pkgfile文件的介绍[点击这里查看](http://gitlab.rd.in.linx/linx6.0.42/documents/blob/master/Pkgfile-yczhu.md)。
* post_mk.sh、post_add.sh：这是两个shell脚本，在执行pkgmk命令时加上-pm、-pa参数，将会在编译二进制包时执行这两个文件，详细介绍见《pkg 命令说明文档V0.2.odt》。
* \*.patch文件、\*.conf文件：软件包的补丁文件和编译软件包的相关配置文件，根据不同的需求会在编译软件包时加入这两个文件。
@@ -127,10 +132,30 @@ cat applications/.gitignore
*.o
*.so.*
```
所有这里列出的文件名将不被跟踪。
在软件包名目录下会出现一些隐藏文件，譬如.footprint*，.md5sum：
* .footprint\*：如果以ls -a浏览软件包名目录里的内容，会发现这一系列的文件有.footprint、.footprint_base、.footprint_ia64_sec、.footprint_ppc64_base、.footprint_x86_64_base、.footprint_x86_64_sec。打开其中任意一个查看其内容，发现这个文件的每一行包含三个字段，结尾处是一个目录名或者文件名。第一个字段描述这一行结尾处文件或目录的属性，第二个字段是这个目录或文件的属主、属组，第三个字段是这个文件或目录的存放路径。这些目录和文件正是在编译二进制包时，会在pkg目录下创建的目录和文件。这个文件也有记录编包过程的作用，如果改动了Pkgfile，导致重新编出的包与上一次编出的包目录或文件有变化，那么pkgmk将会报错。这时候，如果想要更新此.footprint文件，可以用命令pkgmk加上-uf参数来实现。文件名中的ia64、x86_64等表示不同的计算机体系结构，base表示基本包，sec表示的是安全包。
* .md5sum：很明显，这就是md5校验和文件。查看这个文件的内容，会发现这个文件的每一行分为两个字段，第一个字段是一个校验和，第二个字段是这个校验和对应的文件名。实际上，每一个在Pkgfile的source=()中列出的文件，都会有一个校验和存放到这个文件中，当这些文件被改动后，如果不更新被改动文件的校验和，pkgmk命令将会报错，这时可以用pkgmk命令加上-um参数来更新文件的校验和。
最后，还有一点跟软件包名目录下的内容相关的问题。由于历史的原因:smile:，有些目录下会有各种不同的源码包，以及这些源码包需要的补丁文件等，例如上面的示例中列出的firefox目录就是；后来有了新的规则，不再将多余的内容放在软件包名目录下，只放本次编译二进制包用到的文件，这让软件包名目录下的内容显得精炼了不少，例如上面示例中的acct目录就是。
源码包目录下的隐藏文件，有.footprint*，.md5sum：
* .footprint\*：每个源码包目录下都有这一系列的文件，这一系列的文件，记录了针对不同的计算机体系结构，编译出来的二进制报的目录、文件的摆放位置。
* .footprint：记录了不针对任何体系结构时，编译出来的安全包的文件和目录的存放位置
* .footprint_base：记录了不针对任何体系结构时，编译出来的基本包的文件和目录的存放位置；
* .footprint_ia64_sec：记录了针对ia64体系结构的计算机，编译出来的安全软件包的文件和目录的存放位置；
* .footprint_ppc64_base：记录了针对ppc64体系结构的计算机，编译出来的基本包的文件和目录的存放位置；
* .footprint_x86_64_base：记录了针对x86_64体系结构的计算机，编译出来的基本包的文件和目录的存放位置；
* .footprint_x86_64_sec：记录了针对x86_64体系结构的计算机，编译出来的安全包的文件和目录的存放位置。
文件名中的base表示针对基本包的记录，sec表示的是针对安全包的记录。
打开其中任意一个文件查看其内容，发现这个文件的每一行包含三个字段，结尾处是一个目录名或者文件名。
* 第一个字段描述这一行结尾处文件或目录的属性；
* 第二个字段是这个目录或文件的属主、属组；
* 第三个字段是这个文件或目录的存放路径。
这些目录和文件在编译二进制包时，会在pkg目录下创建出来。首次编译rocky6.0.42.41的二进制包时，没有.footprint*系列的文件，编译过程中会生成。如果以后改动了Pkgfile文件，导致重新编出的二进制包与上一次编出的二进制包的摆放目录或文件有所不同，那么pkgmk将会报错。这时候，如果想要更新此.footprint文件，可以用命令pkgmk加上-uf参数来实现。
* .md5sum：这是md5校验和文件。以applications/packages/b/binutils下的.md5sum文件为例，查看这个文件的内容，
```
cat .md5sum
d77fa789b4cae8b1ef7bc10e6220a529 binutils-2.18-GCC43-1.patch
83877c299e3e3080952214e479396f23 binutils-2.18-configure-1.patch
9d22ee4dafa3a194457caf4706f9cf01 binutils-2.18.tar.bz2
```
会发现这个文件的每一行分为两个字段，
* 第一个字段是一个校验和;
* 第二个字段是这个校验和对应的文件名。
实际上，每一个在Pkgfile的source=()中列出的文件，都会有一个校验和存放到这个文件中，当这些文件被改动后，如果不更新被改动文件的校验和，pkgmk命令将会报错，这时可以用pkgmk命令加上-um参数来更新文件的校验和。
最后，还有一点跟源码包目录下的内容相关的问题。由于历史的原因:smile:，有些源码包目录下会有各种不同版本号的源码包，以及这些源码包各自需要的补丁文件等，例如上面的目录树示例中列出的firefox目录。其实，没必要将所有用过的不同版本的源码包以及这些源码包用到的文件都保留下来，每个源码包目录下只需要放置最近一次使用的源码包和它所需要的文件即可。所以，在写作本文档的时候编包，不再将多余的内容放在软件包名目录下，只放本次编译二进制包用到的文件，这让软件包名目录下的内容显得精炼了不少，例如上面示例中的acct目录就是。