search

archlinuxcn / lilac

Lilac is the build bot for archlinuxcn
GNU General Public License v3.0
113 stars 39 forks source link

auto bump pkgrel when rebuilding a package #123

Closed petronny closed 4 years ago

petronny commented 4 years ago

如题，我在mpv-git使用的auto bump代码感觉效果还挺好的。。。 我正在想可不可以把那个设置成默认的行为？

目前想到的问题有：

  1. 原来的自动保留大pkgrel的功能感觉需要去掉
  2. 需要一种新的手动trigger rebuild的方式（比如通过创建一个空的rebuild文件）
lilydjwg commented 4 years ago

我不是很喜欢用带小数点的 pkgrel。 对于不需要与 AUR 保持版本号同步的包，直接用 update_pkgver_and_pkgrel 就可以啦。 可以先给 update_pkgver_and_pkgrel 加一个参数，让它支持小数级的增量。

设置成默认行为的话，如果又在 lilac.py 里更新了，就会造成重复更新。可能需要想办法处理一下。

petronny commented 4 years ago

(手抖不小心给关了。。。)

ok

不过现在的手动trigger rebuild的方式我觉得也可以讨论一下， 因为我做mpv-git的时候，被自动保留大pkgrel的这个功能妨碍了一下， 如果能自动增加pkgrel并通过其他方式trigger rebuild，应该就不需要这个了

petronny commented 4 years ago

首先更新一下，不需要 1.009，1.010 这种小数级的pkgrel 1.009，1.010 和 1.9, 1.10 是等价的

我觉得我们需要一个给pkgrel加后缀的功能，后缀的内容是str，比如.archlinuxcn1 .archlinuxcn2这种

lilydjwg commented 4 years ago

我觉得我们需要一个给pkgrel加后缀的功能，后缀的内容是str，比如.archlinuxcn1 .archlinuxcn2这种

这个与 PKGBUILD(5) 对 pkgrel 的定义冲突了。

为什么要加后缀呢，感觉没有 pacman 的支持的话很难用啊。

petronny commented 4 years ago

那就 1.9, 1.10 这种吧。

加小数主要是为了保持不超过AUR上游的pkgrel

str后缀其实是想让用户更清楚这个更新的来源是哪

lilydjwg commented 4 years ago

来源的话，最好的办法是 pacman 支持记录来源。 我不是很喜欢加小数，感觉怪怪的。AUR 上游其实挺麻烦挺麻烦的，所以我一向把 AUR 作为下游用的。

petronny commented 4 years ago

话说这个feature是不是已经有了？

lilydjwg commented 4 years ago

现在还是在 pre_build 里实现的吧。

petronny commented 4 years ago

对，我感觉现在有一个每次+1的功能。新加的包也能+1。应该也算解决了当时的问题？

lilydjwg commented 4 years ago

那就算解决了吧。有问题再开 issue。

lilydjwg commented 4 years ago

我打算在 lilac 里实现这个：如果 pre_build 没有更新 pkgver 和 pkgrel，那就更新 pkgrel。 然后 pre_build 里就可以省略这个逻辑，同时它包括这个逻辑也不影响。

这样可能会造成 pkgrel 跳跃。不过应该没啥负面影响。

cc @yuyichao

petronny commented 4 years ago

吼啊

其实我在想那个防止打老包的功能是不是可以转移到这来得了？ 只需要保证每次都是递增的就行。 也就不需要从arch repo里读数据了。 有特例不过手动处理就好了吧？

然后group检测那个我还是建议默认把group删了，就是匹配到groups=的行删 如果真的有需要的话，lilac.yaml中加一个keep_group参数 然后就可以彻底解脱arch repo了。

lilydjwg commented 3 years ago

其实我在想那个防止打老包的功能是不是可以转移到这来得了？

那个代码本来就在附近呀。不从包数据库读数据，lilac 打包出来的版本比手工打包上传的低怎么办？group 检测的话，其实可以预先生成数据供 lilac 使用的。

petronny commented 3 years ago

lilac 打包出来的版本比手工打包上传的低怎么办？

最终目的不是去掉手工么。。。至少lilac负责的不再支持手工。 再说都手工了，那就做额外手工处理呗。。。

group检测我觉得还是麻烦。。。 就是感觉做好了麻烦。。。还得多arch多repo不同处理，但意义又不大。。。 去掉了感觉也没啥影响，实在不行加一个meta package 所以我觉得简单点的就够用

lilydjwg commented 3 years ago

最终目的不是去掉手工么。。。至少lilac负责的不再支持手工。

不是。

去掉了感觉也没啥影响，实在不行加一个meta package

这个功能就是因为给用户造成过很大的困扰才加上的。

petronny commented 3 years ago

这个功能就是因为给用户造成过很大的困扰才加上的。

呃我是想说 把所有group都去掉 也没啥影响。。。不是去掉group检测

lilydjwg commented 3 years ago

哦。那是好像没啥人用。不过想要去掉包数据库的依赖的话，replaces 怎么办呢？

petronny commented 3 years ago

replaces现在有检查么？

总之我觉得也是默认删，如果真有必要那么加个allow_replaces参数指定不删

lilydjwg commented 3 years ago

有检查啊。而且 replaces 有用啊。加参数的方法又不进行检查。

petronny commented 3 years ago

没检查吧。。。lilac2.pkgbuild里只有ConflictWithOfficialError和DowngradingError吧。。。

petronny commented 3 years ago

我觉得首先replaces本身就是罕见情况，哪怕发生了，下述3种情况中我认为2种是删了为好，1种是不删用户自己也能处理：

  1. replaces 官方源包 那么肯定删了是好的
  2. replaces 另一个仍然存在的AUR包 这就是引战的节奏，比如 https://github.com/archlinuxcn/repo/blob/master/archlinuxcn/aurvote/PKGBUILD#L12 我现在手动装aur/aurvote-git的话，一更新就会被替换成aurvote aurvote-git的用户和维护者不得气死。。。 应该是写好provides和conflicts就行了
  3. replaces 另一个已经不存在了的AUR包 我觉得写好了冲突关系让用户自己解决就行了。 用户一看一个包连AUR上游都没了肯定自己就删了啊。。。

另外lilac2.api.add_replaces没有一处被用到。。。 也就是现在的replaces完全来自于AUR自带的。 我觉得AUR的PKGBUILD中replaces出问题的概率还挺大的，尤其是前2种情况 但第三种情况下，AUR一个包被替换了，但是新包根本就没写replaces的情况也有很多，用户还是能自己解决的。

总之我还是觉得删，然后实在有需要的加allow_replaces。 groups也是allow_groups。

lilydjwg commented 3 years ago

并不是所有包都来源于 AUR，而你一直在说 AUR……

删可以，不过依然避免不了依赖包数据库，因为检查还是要检查的。