koji使用外部仓库

序言

使用koji来编译rpm包时，因为rpm包会依赖很多的其他的rpm包，而这时我们自己的build tag对应的rpm包又不足够时，我们就会使用外部仓库来提供依赖包，那么koji如何选择依赖包来自于build tag对应仓库还是来自于外部仓库呢？同时又会有什么样的条件呢？这就和我们引进外部仓库时使用的合并模式（merge mode）及优先级等等一些选项相关了。

引进外部仓库

使用指令就可以新建外部仓库

$ koji add-external-repo -t dist-foo-build dist-foo-external-repo http://repo-server.example.com/path/to/repo/for/foo/\$arch/

我们看下add-external-repo的help:

$ koji add-external-repo --help
Usage: koji add-external-repo [options] <name> [<url>]
(Specify the --help global option for a list of other help options)Options:-h, --help            show this help message and exit-t TAG, --tag=TAG     Also add repo to tag. Use tag::N to set priority-p PRIORITY, --priority=PRIORITYSet priority (when adding to tag)-m MODE, --mode=MODE  Set merge mode-a ARCH1,ARCH2, ..., --arches=ARCH1,ARCH2, ...Use only subset of arches from given repo

koji add-external-repo [options] []，options指定一些选项，name就是你给这个外部仓库的命名，url即为仓库的网址

看下option:

• -t则指定为哪一个build tag引进的这个外部仓库
• -a即为体系结构
• -p是优先级，比如说你增加了几个外部仓库，如果有一个包在这几个外部仓库都有，如何选择可能就和优先级有关，选择优先级高的那个仓库来获取包。不指定的话，koji按照FIFO的形式指定优先级（值越小优先级越高）
• -m 合并仓库的模式，koji列出来三个模式koji, bare, simple, 不指定的话默认是koji

合并模式

添加了外部仓库，koji就会将原来的仓库（build tag对应的）和外部仓库进行合并，然后使用时就会从这个新的仓库里边取用rpm包，如何合并就是和我们下边讲到的合并模式有关了。

1. koji

这里koji是指合并模式，即使用-m koji指定，也是最基本的模式。合并到新仓库的包并不是说简单把所有的仓库的包混进来，选择包的条件要对应到srpm，首先会从仓库中的rpm包对应的srpm中选择一个srpm，找到这个srpm（可能不同仓库都有这个srpm<比对全名>）下对应的所有rpm包添加到新仓库，相同的包只添加一次。那么按照什么顺序选择这一个srpm呢，就是按照“原来仓库”到“外部仓库”顺序，外部仓库按照优先级顺序依次。找这个srpm下对应rpm包也是按照以上相同规则顺序来添加，相同的rpm包只会添加一次。这种模式下的包是基本上不会出现同名的包，除非说某一个仓库下srpm编译出来的多个相同名字的rpm包。

这里及后边所说的“原来的仓库”其实是指改tag下对应rpm包，也即被打进这个tag的所有的rpm包形成的仓库

内部使用的是mergerepos_c --koji命令

2. bare

使用此合并模式，就会将所有的包合并到一处，但是当如果相同包名，需要他的EVRA(epoch-version-release-arch)（其实主要是relase或者version）不一样才可以合并。这样的话仓库就会出现很多有着相同名字，但是版本（version）或者发行（release）不同的包。这很适合用在centos8引入的module的概念。即: 使用一个仓库，可以切换不同的version/release的软件。

内部使用的是mergerepos_c --pkgorigins --all命令，不过需要安装createrepo_c的0.14版本（支持libmodule）及以上，不然就是如果拥有相同NEVRA(name-epoch-version-release-arch)那就只选择第一个rpm。选择的规则和koji模式还是一样，首先选择原仓库，原仓库没有再按找优先级从外部仓库开始选用。

3.simple

这中模式限制比较少，甚至可以接受相同的NEVRA(name-epoch-version-release-arch)的包

内部使用的是 mergerepos_c --mode simple 指令，simple是createrepo_c 0.13引入的组件，使用它的理由有：a). 想要使用bare，但是版本比较低，用来替代bare模式，b). 你真的就是想要仓库的包有着相同的NEVRA(name-epoch-version-release-arch)的包

总结一下就是正常情况下就是使用koji，如果你希望你的仓库有相同包名但是不同版本（version）或者发行（release）就使用bare，基本不会用到simple，要么用来达到bare的功能，要么就是希望仓库中有的包有相同的NEVRA(name-epoch-version-release-arch)。

实验一下

1. 创建本地仓库

首先我们先创建一个本地的build tag：

$ koji add-tag --arches="x86_64 aarch64" test-merge-mode-build-tag

然后我们往这个tag里增加一个包libuser:

$ koji add-pkg --owner=[你的账号] test-merge-mode-build-tag libuser
$ koji tag-build test-merge-mode-build-tag libuser-0.62-23.el8
$ koji regen-repo test-merge-mode-build-tag

然后我们就生成了仓库，关于yum仓库详细信息，参考这里)，我们看下这个仓库的包的情况，下载仓库的primary.xml.gz打开查看：

隐藏了一些信息，libuser-0.62-23.el8的srpm会编译三个包，那我们这里就可以看到libuser，libuser-devel，python3-libuser这三个包。location表示包所在的位置，可以看到是在当前仓库的/toplink/packages/libuser/0.62/23.el8/x86_64/这里找到

如果你编译只需要libuser这一个包的话，就可以用test-merge-mode-build-tag作为build tag来编译了，不过实际情况下肯定不会是只依赖这一个包。

2. 添加外部仓库

我们添加rocky和fedora的镜像下的仓库进来。首先使用koji的合并模式

$ koji add-external-repo -t test-merge-mode-build-tag -p 5 -m koji -a "x86_64 aarch64" test_merge_mode_rocky_base http://mirrors.sjtug.sjtu.edu.cn/rocky/8/BaseOS/\$arch/os/
Created external repo 58
Added external repo test_merge_mode_rocky_base to tag test-merge-mode-build-tag (priority 5)$ koji add-external-repo -t test-merge-mode-build-tag -p 10 -m koji -a "x86_64 aarch64" test_merge_mode_fedora http://mirror.sjtu.edu.cn/fedora/linux/development/36/Everything/\$arch/os/
Created external repo 59
Added external repo test_merge_mode_fedora to tag test-merge-mode-build-tag (priority 10)

我们新加了优先级是5的test_merge_mode_rocky_base和优先级是10的test_merge_mode_fedora的仓库，test_merge_mode_rocky_base优先级高于test_merge_mode_fedora

然后看下这个tag下的信息：

然后我们再重新生成下这个repo:

$ koji regen-repo test-merge-mode-build-tag

2.1 验证koji合并模式

继续下载下来primary.xml.gz文件查看，不过这次文件就非常大了，打开也要很久

这次看到这个repo下就有66612个包了，我们看到第一个rpm的名字0ad，然后位置是在https://mirror.sjtu.edu.cn/fedora/linux/development/36/Everything/x86_64/os/Packages/0/这里。是因为0ad这个包在原来仓库和test_merge_mode_rocky_base仓库没有，所以才会选择来自test_merge_mode_fedora仓库。

这样就完成了合并，那其实关心的是libuser这个包现在是选择哪个仓库的呢：

可以看到libuser(x86_64)这个仓库依然来自于本地仓库。证明说如果每个仓库都有这个文件，优先选择原仓库。但是还有一个libuser(i686)的这就是说test_merge_mode_rocky_base仓库真的编译了同名两个包，首先libuser在原来的仓库选择rpm后，会继续到外部仓库去选择，如果之前没有选择就会加进来。

另外我们加入的test_merge_mode_fedora的仓库下的authselect这个rpm包比test_merge_mode_rocky_base高，但是是选用的test_merge_mode_rocky_base的仓库的包。所以证明适合rpm版本高低没有关系，只是和仓库的优先级有关。

2.2 验证bare合并模式

那我们把模式切换成bare，重新生成下仓库

$ koji edit-external-repo -m bare test_merge_mode_fedora --tag test-merge-mode-build-tag
$ koji edit-external-repo -m bare test_merge_mode_rocky_base --tag test-merge-mode-build-tag
$ koji regen-repo test-merge-mode-build-tag

生成完之后我们继续下载primary.xml.gz文件，这次文件比上次的还大，我们直接来看下libuser这个rpm包：

可以看到有好多libuser包，首先我们新建的tag包含libuser这个rpm包时x86_64中的arch只有x86_64，但是我们引入的外部仓库还有i686这个arch。首先要声明的是我们选择的libuser是和test_merge_mode_rocky_base中一样的，只是缺少i686的包，所以libuser-0.62-23.el8.x86_64.rpm这个包是来自于原来的仓库，没有的i686包(libuser-0.62-23.el8.i686.rpm)就会引入test_merge_mode_rocky_base仓库中的包。但是test_merge_mode_fedora仓库中libuser又是和其他仓库的版本不一样，所以test_merge_mode_fedora中的libuser也会包含进来。总结下就是如果有一个包的相同NEVRA（name-epoch-version-release-arch）同时存在于大于等于两个仓库时，就会遵循首先原始仓库，原始仓库如果没有就按照优先级选用外部仓库的策略。如果一个包存在NEVRA不同，就会统统包含进来。

关于simple用的比较少，大家可以自行去实验一下。

3. yum/dnf安装一下

上边我们从仓库内部已经看到了合并后的仓库，那我们从这个仓库安装又会是什么样呢？我们来实验一下，以bare模式为例（其他的模式类似）：

首先我们把合并后的仓库放到/etc/yum.repos.d/中

$ cd /etc/yum.repos.d/
$ cat << EOF > test_koji_repo.repo
> [test-koji-repo]
> name=test-koji-repo
> baseurl=http://xxxxxx[你的koji地址]/kojifiles/repos/test-merge-mode-build-tag/latest/x86_64/
> enabled=1
> gpgcheck=0
> EOF

然后把其他的repo文件备份后删掉，使得这个文件夹下只有这一个repo文件

然后使用dnf安装libuser试试：

$ dnf clean all
$ dnf install libuser --allowerasing

安装当然会不成功，首先我本机有安装libuser，另外我们创建的这个仓库还有有些依赖包缺失，最后本地安装的包还有冲突。我们就简单测试安装一下，使用–allowerasing（allowerasing表示覆盖冲突的包），我们仅仅列出来不做安装，然后看下结果：

Last metadata expiration check: 0:06:05 ago on Fri 11 Mar 2022 02:59:09 PM CST.
Dependencies resolved.
================================================================================Package     Architecture      Version        Repository           Size
================================================================================
Installing:libuser      x86_64          0.63-7.fc35     test-koji-repo       380 k

哈，可以看到拉取的仓库是test-koji-repo，但是安装的版本却是0.63-7.fc35，因为我们仓库里有这个包，且这个包版本还大于我们原本仓库的包。

当然我们也可以指定需要的版本的包：

$ dnf install libuser-0.62-23.el8 --allowerasing
Last metadata expiration check: 0:11:20 ago on Fri 11 Mar 2022 02:59:09 PM CST.
Dependencies resolved.
=================================================================================Package       Architecture       Version         Repository        Size
=================================================================================
Installing:libuser         x86_64          0.62-23.el8     test-koji-repo      413 k

这样也可以证明我们仓库同时拥有两个版本的libuser包。

总结

本篇文章我们讲述了如果添加外部仓库为我们所用，当我们需要用到的包不够用，就需要借助外部仓库来使用。那么就会涉及到选用包是从哪个仓库来选择，当我们添加外部仓库会指定一个合并模式及优先级，根据不同的这些选项我们会产生一个新的仓库。我们着重的讲解了不同的合并模式，koji模式包名不会重复，bare模式下包名可能会重复，只要NEVRA其中一个不一样就可以，simple模式下就是把所有的包简单的混合一下，不做什么处理。另外我们也根据例子详细罗列一下。