archlinuxcn / lilac

如题。

_repo_package_versions永远是x86_64的那个。（还是不同arch的同名包只取最新的那个？）
非x86_64的不应该读这个的。

建议把build_prefix传给check_srcinfo，然后取最后一段当做arch再做判断吧

multilib特判成x86_64

PS. 我目前用到的各种奇怪的build_prefix有：

extra-x86_64, multilib
extra-armv6h, extra-armv7h, extra-aarch64
action-extra-*, action-multilib
skip-*, action-skip-*
例如 skip-aarch64-build
这个是跳过archbuild，通过pre_build直接下载其他地方打好的包，例如
https://github.com/arch4edu/arch4edu/blob/master/linux-raspberrypi4-aarch64/lilac.py

头疼……这部分并不支持官方 Arch 之外的发行版。做起来也挺麻烦，还不一定能成功。倒是可以对其它发行版的包，把这部分跳过。

那我跳过吧。。。

啊，我的鍋...當初沒有想到不同arch版本可能不同的問題，因為Arch還支援i686的時候，x86_64和i686通常是同時更新的

_repo_package_versions永远是x86_64的那个。（还是不同arch的同名包只取最新的那个？）

嗯都不是，是看包在*.db中的順序

lilac/lilac2/pkgbuild.py

Line 95 in d039393

_repo_package_versions = {p.name: p.version for p in db.pkgcache}

或許可以改成 (not tested)

    arch = build_prefix.split('-')[-1]
    if arch == 'multilib':
        arch = 'x86_64'
    _repo_package_versions = {p.name: p.version for p in db.pkgcache if p.arch == arch}

那我跳过吧。。。

跳過會有問題。這段code是用來防止打出舊版本的包。如果x86_64是1.0.0-10，aarch64要是從1.0.0-8升級到1.0.0-9會失敗。

如果x86_64是1.0.0-10，aarch64要是從1.0.0-8升級到1.0.0-9會失敗。

对。。。就是这个情况。。。

我试试改改

_repo_package_versions 并不需要为每个架构单独处理。它需要为每个发行版+架构单独处理。现有逻辑在只支持 Arch Linux (x96_64) 的时候是没有问题的，alarm、Arch linux 32 那些会有问题。

发行版这个问题就更大了，我今天还想来着。
架构不重叠是一种情况，架构重叠是另一种情况了。

archlinux和alarm好在是架构不重叠，我认为放到同一个lilac repo里没事。
_repo_package_versions只做个多架构支持就行。。。

但还有架构重叠的，比如如果要做yay和yay-manjaro的话，即后者是用manjaro-x86_64打包，情况会复杂很多了。

不光_repo_package_versions要改，
现在lilac的ini配置文件里写死了只会向一个arch repo输出，
真要支持多发行版那得在这里支持多repo，然后在lilac.py中设置是哪个repo。

总之我觉得archlinux, alarm, Arch linux 32放在同一个arch repo里面，靠架构区分没事。
manjaro单独放一个arch repo，万一哪天有manjaro-arm了，就也放这个里。

但archlinux, alarm, Arch linux 32, manjaro, manjaro-arm这些要不要放同一个lilac repo我觉得有待讨论。
实在不行分2个得了。。。

然后还有一个地方也有多arch repo输出的需求。
就是包A可下载打包不可分发，但基于包A的包B可分发。
这时候要让lilac打A，但是A输出到private repo（或者不输出）
然后lilac就可以正常打B了

我记得原先有个dropbox的例子

总之总结一下是，
有个问题是要不要做到多个arch repo的输出？
然后无论做不做，都要做_repo_package_versions的多arch改进
做的话还要有多arch repo的改进

多repo我覺得不一定需要。當初討論[archlinuxcn-testing]的時候 [1] 我有考慮過這點。看了code之後，覺得跑多個lilac，用不同的config.ini比較容易做。

[1] archlinuxcn/repo#976

多个发行版 / repo，你跑多只 lilac 就好了呀。（所以其实 alarm 应该单开一只 lilac。）
当然 lilac 并没有在同一服务器、同一用户、同一 git repo、同一 github 用户下跑多只的支持。可能会有问题，需要慢慢改。

只打包不输出这个要做也不难，只要添加一个配置项，出包之后不调用 cp -l 就行了。

多只不如一只。。。
现在一只的多打包session还没上线，
多只岂不是要独立维护一个session管理。。。难道部署个redis不成。。。？

这种情况下我站多arch repo输出

不过现在是多arch就够用。。。

多session是指 #145 ？那的確多隻不容易做...

这个在 pre_build() 函数里设置 os.environ['CARCH'] = 'xxx' 应该有用。

我现在的解决方案是先对老 PKGBUILD 求一次版本号，然后拖 PKGBUILD，再 makepkg -od --noprepare ，然后再求一次版本号，然后比较新旧。。

pkgbuild.check_srcinfo对多arch的支持不好