search

xiaorouji / openwrt-passwall

7.21k stars 2.65k forks source link

[Bug]: 通过release版本更新发生错误 #2464

Closed WROIATE closed 1 year ago

WROIATE commented 1 year ago

描述您遇到的bug

Not downgrading package luci-app-passwall on root from 4.62-3 to 4.62

貌似release没带上小版本号，导致无法正常安装

复现此Bug的步骤

opkg install

您想要实现的目的

能够使用新版本进行更新

日志信息

opkg install luci-app-passwall_4.62_all.ipk                
Multiple packages (libgcc1 and libgcc1) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (libgcc1 and libgcc1) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (libgcc1 and libgcc1) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (libatomic1 and libatomic1) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (libatomic1 and libatomic1) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (libstdcpp6 and libstdcpp6) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (libstdcpp6 and libstdcpp6) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (libstdcpp6 and libstdcpp6) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (libstdcpp6 and libstdcpp6) providing same name marked HOLD or PREFER. Using latest.
Not downgrading package luci-app-passwall on root from 4.62-3 to 4.62.
Collected errors:
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-crypto-hash
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-crypto-null
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-crypto-aead
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-crypto-manager
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-crypto-authenc
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-nf-reject
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-nf-ipt
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-nf-log
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-ipt-core
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-nfnetlink
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-ipt-ipset

截图

No response

系统相关信息

lean lede R23.4.1

其他信息

No response

Deleted-Account commented 1 year ago

--force-downgrade

nftbty commented 1 year ago

我也挺希望能解决这个问题，可惜，官方SDK编译出来的luci默认就这样，不带PKG_RELEASE。 在官方仓库找了几个包，带小版本号的都是直接 PKG_VERSION=1.0.3-1 这样的。再很多都没有版本号。或许可以像某些官方收录的luci app 一样，直接使用PKG_VERSION=4.63-1 这样的形式，这样使用第三方编译和官方编译出来的版本号都是一样的。@smallprogram 这样改的话，拉取新代码后编译，也不会产生影响，只要把自动编译的版本号检测适配一下就可以。 https://github.com/openwrt/luci/blob/2145121d4cf766e8ea3340e08f8bc76ba5c513fc/applications/luci-app-simple-adblock/Makefile#L8 PKG_VERSION:=1.9.3-3 https://github.com/openwrt/luci/blob/2145121d4cf766e8ea3340e08f8bc76ba5c513fc/applications/luci-app-pbr/Makefile#L8 PKG_VERSION:=1.1.0-1 https://github.com/openwrt/luci/blob/2145121d4cf766e8ea3340e08f8bc76ba5c513fc/applications/luci-app-https-dns-proxy/Makefile#L8 PKG_VERSION:=2022-10-15-11 这是几个官方收录的luci app的版本号组成，都是直接使用的PKG_VERSION。

WROIATE commented 1 year ago

--force-downgrade

依然不行

root@OpenWrt:/tmp/upload# opkg install luci-app-passwall_4.63_all.ipk --force-downgrade
Multiple packages (libgcc1 and libgcc1) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (libgcc1 and libgcc1) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (libgcc1 and libgcc1) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (libatomic1 and libatomic1) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (libatomic1 and libatomic1) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (libstdcpp6 and libstdcpp6) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (libstdcpp6 and libstdcpp6) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (libstdcpp6 and libstdcpp6) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (libstdcpp6 and libstdcpp6) providing same name marked HOLD or PREFER. Using latest.
Package luci-app-passwall (4.62-3) installed in root is up to date.
Collected errors:
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-crypto-hash
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-crypto-null
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-crypto-aead
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-crypto-manager
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-crypto-authenc
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-nf-reject
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-nf-ipt
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-nf-log
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-ipt-core
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-nfnetlink
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-ipt-ipset
 * pkg_hash_check_unresolved: cannot find dependency luci-lua-runtime for luci-app-passwall
nftbty commented 1 year ago

试了一下，确实有大问题，首先opkg的参数 --nodeps查任何资料都是不遵循依赖安装，但是这里加了没加没任何区别。那这个参数意义何在。而且同时加上--force-downgrade和--force-depends输出也没有任何变化。其实我前段时间就在一个PR下面发了长篇吐槽这个把可选组件作为依赖的问题，链接在这。这就正好是里面提到的会产生的不好的结果。 当然这里还有个更大的问题，就是这些包都是使用snapshots/master分支的SDK编译的，而根据OpenWrt官方论坛的一个帖，下面有回复提到，master的luci做出了很大的改变，和22.03及以前的版本都不太兼容：

Only the LuCI master has been converted to the ucode based approach by jow and 22.03 is unlikely to change.

而关于luci使用ucode的细节在这里，就是上面论坛帖里提到的jow发的。luci转向ucode，整个lua的部分只为了兼容性考虑而保留。因为passwall本来就是基于luci1的，连客户端渲染的jsluci或者叫luci2都不是，更不用说ucode-luci了。所以master版为了旧版luci-app的兼容性，专门弄了个luci-lua-runtime包，凡是使用新版SDK编译的ipk，都强制加上了这个lua环境包。而这个包在22.03，及以前版本（包括国内各种改版）都是没有这个包的，因为不需要。 所以为了适用与大部分设备（用passwall的主要是中国用户，主要都是luci1的改版op），最多只能使用22.03的SDK编译，而且按第一个发的论坛帖所说，22.03的SDK其实也是有问题的，跟master一样添加了对luci-lua-runtime的依赖，不知道这个问题修复了没有，没有的话，只能基于21版的SDK了。如果要照顾到使用官方最新版op的用户的话（其实首先要看有没有兼容性问题，在新版luci能不能跑起来），如果之前编译安装过passwall，说明依赖齐全，直接装旧版SDK生成的ipk也不会有问题，如果是新装，一般自己用SDK编译第一版装上就行了。或者新版luci兼容性没问题的话，可以专门再添加一个master版SDK的自动编译。 然后就是可选包的以来问题，解决根本的话，就是直接改为select的形式而不采用依赖，不动这一块只解决生成包的依赖问题，就编译选项什么可选项都不要选，最小编译，这样所有用户都可以自由安装，或者自由升级，选择自己需要的插件，省心省力。

nftbty commented 1 year ago

而且从现在情况看，--force-depends --nodeps根本就没有用，依赖问题不解决都不是我很久以前吐槽的麻烦的问题了，而是直接装不了了。如果按照真去安装依赖，不说用户不需要那些，就是为了升级不得不安装那些不需要的包，也没这么大容量来安装这些。我先在我自己的分支尝试下。

nftbty commented 1 year ago

--force-downgrade

依然不行

版本号一个强制降级就可以了，主要是依赖项的问题，你也可以看看2463下面有人提的这个问题。然后看我上面的评论。 建议标题改一下，强调一下问题发生的原因，然后描述也相应改一下。

smallprogram commented 1 year ago

我也挺希望能解决这个问题，可惜，官方SDK编译出来的luci默认就这样，不带PKG_RELEASE。 在官方仓库找了几个包，带小版本号的都是直接 PKG_VERSION=1.0.3-1 这样的。再很多都没有版本号。或许可以像某些官方收录的luci app 一样，直接使用PKG_VERSION=4.63-1 这样的形式，这样使用第三方编译和官方编译出来的版本号都是一样的。@smallprogram 这样改的话，拉取新代码后编译，也不会产生影响，只要把自动编译的版本号检测适配一下就可以。 https://github.com/openwrt/luci/blob/2145121d4cf766e8ea3340e08f8bc76ba5c513fc/applications/luci-app-simple-adblock/Makefile#L8 PKG_VERSION:=1.9.3-3 https://github.com/openwrt/luci/blob/2145121d4cf766e8ea3340e08f8bc76ba5c513fc/applications/luci-app-pbr/Makefile#L8 PKG_VERSION:=1.1.0-1 https://github.com/openwrt/luci/blob/2145121d4cf766e8ea3340e08f8bc76ba5c513fc/applications/luci-app-https-dns-proxy/Makefile#L8 PKG_VERSION:=2022-10-15-11 这是几个官方收录的luci app的版本号组成，都是直接使用的PKG_VERSION。

意思，在编译拉去源码后，我强制把 

PKG_VERSION:=4.62
PKG_RELEASE:=7

改为

PKG_VERSION:=4.62-7

把PKG_RELEASE干掉就行了对吗？

nftbty commented 1 year ago

我意思不是你编译的时候改，而是跟那些项目一样，直接不用PKG_RELEASE了，反正luci编译也不认，就直接改源码，以后就直接4.62-7这样就行，这个改动也不会带来什么影响，唯一影响到的就是你自动编译抓取版本号的部分。可以两个修改先pr上去，先合并Makefile修改，紧接着就合并自动编译的修改，就不会有问题。这个需不需要xiaorouji做决定？

smallprogram commented 1 year ago

我意思不是你编译的时候改，而是跟那些项目一样，直接不用PKG_RELEASE了，反正luci编译也不认，就直接改源码，以后就直接4.62-7这样就行，这个改动也不会带来什么影响，唯一影响到的就是你自动编译抓取版本号的部分。可以两个修改先pr上去，先合并Makefile修改，紧接着就合并自动编译的修改，就不会有问题。这个需不需要xiaorouji做决定？

自动编译这部分我这没问题，可以改，PKG_RELEASE这块最好问问 @xiaorouji

nftbty commented 1 year ago

来回测试多次，终于算是大概搞清楚这里面的逻辑了。那个官方论坛里最后有回复，是22.03的SDK使用了master版的luci仓库，导致产生了luci-lua-runtime的依赖。 据此，做了测试，使用snapshots的SDK，把feeds.conf里面luci源换为22.03版，编译出来的ipk就没有luci-lua-runtime的依赖。因为我编译的时候没有选择任何可选项，所以没有任何额外依赖，成功安装到系统。 进一步测试是否master版luci兼容性问题引起的--nodeps和--force-depends参数都无法安装，重编译了一版加上V2ray依赖的ipk（我op没装V2ray），然后使用--nodeps和--force-depends参数安装，无效，还是会提示依赖问题。看来装不上的问题，不是什么别的复杂的原因，就是有依赖问题不满足，而且无视依赖安装的参数不知为什么无效。 目前看来，要编译出适合所有人的版本，最高只能使用22.03版的luci源，SDK版本无关，然后passwall的插件选项要全部取消，只能有必要的依赖。这样生成的ipk才所有设备都可安装。 但这里还存在一个问题，就是如果之前的版本是通过passwall的菜单项选择的插件，这些插件在系统是被标记为自动安装，更新无插件依赖的版本时，这些插件会被自动移除，需要使用--force-reinstall参数安装。 当然产生这个麻烦的根本原因还是在于本该使用select选择的插件，使用了添加依赖的方式。本来22年10月6日的 #2118 提交是为了解决这个问题的，可惜后来因为某些根本不是问题的问题，被revert了。当然这个提交里面也不是完全没问题，那样修改以后，还要在menu "Configuration"下面加一行depends on PACKAGE_$(PKG_NAME)，就没有任何问题了。 可惜。

2eronia commented 1 year ago

这个repo的release中的4.63，提示我需要包括luci-lua-runtime，我倒是可以--force-depends安装上去。固件还是两年前刷的x86 OpenWRT

chunfengyao commented 1 year ago

是不是可以把依赖分离开？luci-app-passwall和i18n语言包都是前端的部分，只是负责页面和生成配置文件以及控制，至于原先依赖的组件可以通过查询opkg判断到底安装了哪些组件。 这样是不是可以做成，luci-app-passwall和i18n完全独立，不依赖其它组件？就不存在安装的时候的依赖版本号问题了。

另外，依赖分离时，可以在luci-app-passwall中给每个需要分离的组件添加一个类似装饰器模式的脚本（相当于组件的功能代理、替身）。在这个脚本中检测组件是否已安装，如果使用到的某个组件未安装，让脚本直接通过UI弹窗提示用户，甚至可以直接跳转到安装页面？ 这样的话，相当于动态依赖，所以，和依赖相关的逻辑，都可以写到组件对应的装饰器模式的脚本中。luci-app-passwall就只需要关注UI和控制就好了。

chunfengyao commented 1 year ago

是不是可以把依赖分离开？luci-app-passwall和i18n语言包都是前端的部分，只是负责页面和生成配置文件以及控制，至于原先依赖的组件可以通过查询opkg判断到底安装了哪些组件。 这样是不是可以做成，luci-app-passwall和i18n完全独立，不依赖其它组件？就不存在安装的时候的依赖版本号问题了。

另外，依赖分离时，可以在luci-app-passwall中给每个需要分离的组件添加一个类似装饰器模式的脚本（相当于组件的功能代理、替身）。在这个脚本中检测组件是否已安装，如果使用到的某个组件未安装，让脚本直接通过UI弹窗提示用户，甚至可以直接跳转到安装页面？ 这样的话，相当于动态依赖，所以，和依赖相关的逻辑，都可以写到组件对应的装饰器模式的脚本中。luci-app-passwall就只需要关注UI和控制就好了。

我这边是编译的时候直接把passwall加到feeds中的，而且，没有全选所有功能（这个情况应该是比较常见的），最近发现passwall通过actions打包了ipk，但是，这种情况下，在通过ipk进行升级的时候，那些编译时没选中的包就无法通过依赖校验了。

WYC-2020 commented 1 year ago

这玩意基本依赖很多的，搞升级有的你们折腾，因为这些基础依赖是必须的，如果确定没这些也能用，那就强制安装就行了，但是到时候出问题又不知道所以然，到时候又是一堆的issue，并且这些基础依赖很多都和内核版本挂钩，有你们玩的了

chunfengyao commented 1 year ago

cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f)

描述您遇到的bug

Not downgrading package luci-app-passwall on root from 4.62-3 to 4.62

貌似release没带上小版本号，导致无法正常安装

复现此Bug的步骤

opkg install

您想要实现的目的

能够使用新版本进行更新

日志信息

opkg install luci-app-passwall_4.62_all.ipk                
Multiple packages (libgcc1 and libgcc1) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (libgcc1 and libgcc1) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (libgcc1 and libgcc1) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (libatomic1 and libatomic1) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (libatomic1 and libatomic1) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (libstdcpp6 and libstdcpp6) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (libstdcpp6 and libstdcpp6) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (libstdcpp6 and libstdcpp6) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (libstdcpp6 and libstdcpp6) providing same name marked HOLD or PREFER. Using latest.
Not downgrading package luci-app-passwall on root from 4.62-3 to 4.62.
Collected errors:
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-crypto-hash
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-crypto-null
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-crypto-aead
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-crypto-manager
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-crypto-authenc
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-nf-reject
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-nf-ipt
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-nf-log
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-ipt-core
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-nfnetlink
 * pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f) for kmod-ipt-ipset

截图

No response

系统相关信息

lean lede R23.4.1

其他信息

No response

你这边的cannot find dependency kernel (= 5.15.105-1-e469f5589b4c7b368924a6e4f8f7407f)，我当时是直接改的.vermagic文件，（如下图，在编译系统生成随机的.vermgic之后，再使用固定值覆写一下）。

image

至于.vermagic的值，就是kernel组件（kmod）的版本号。比如22.03.0的kernel组件（kmod）的下载源。

https://openwrt.proxy.ustclug.org/releases/22.03.0/targets/x86/64/kmods/5.10.138-1-789565457d2f287975d7d943ddbe4eeb/

那么.vermagic的值就是链接的最后的5.10.138-1-789565457d2f287975d7d943ddbe4eeb后面那段789565457d2f287975d7d943ddbe4eeb。

然后就不会有kernel的版本号依赖问题了。

或者，就是只使用官方的imagebuilder进行编译，也不会有这个问题。

另外，passwall通过action进行编译的ipk目前是只适用于snapshot的（使用的是snapshot的openwrt sdk），所以，其它版本的openwrt安装ipk时，都会报kmod模块版本的错。

chunfengyao commented 1 year ago

这玩意基本依赖很多的，搞升级有的你们折腾，因为这些基础依赖是必须的，如果确定没这些也能用，那就强制安装就行了，但是到时候出问题又不知道所以然，到时候又是一堆的issue，并且这些基础依赖很多都和内核版本挂钩，有你们玩的了

passwall项目已经考虑了依赖的缺失问题了，并且，也是支持某些组件的不加载的。 项目中有些地方写的时候就是加了判断是否存在的，另外，编译的时候，也不是所有的组件都是必选组件。 我这边只添加了这几个组件：

CONFIG_PACKAGE_luci-app-passwall=y
CONFIG_PACKAGE_luci-app-passwall_Nftables_Transparent_Proxy=y
CONFIG_PACKAGE_luci-app-passwall_INCLUDE_ChinaDNS_NG=y
CONFIG_PACKAGE_luci-app-passwall_INCLUDE_Haproxy=y
CONFIG_PACKAGE_luci-app-passwall_INCLUDE_V2ray=y
CONFIG_PACKAGE_luci-app-passwall_INCLUDE_Xray=y
CONFIG_PACKAGE_luci-i18n-passwall-zh-cn=y

一切正常反正。

WYC-2020 commented 1 year ago

这玩意基本依赖很多的，搞升级有的你们折腾，因为这些基础依赖是必须的，如果确定没这些也能用，那就强制安装就行了，但是到时候出问题又不知道所以然，到时候又是一堆的issue，并且这些基础依赖很多都和内核版本挂钩，有你们玩的了

passwall项目已经考虑了依赖的缺失问题了，并且，也是支持某些组件的不加载的。 项目中有些地方写的时候就是加了判断是否存在的，另外，编译的时候，也不是所有的组件都是必选组件。 我这边只添加了这几个组件：

CONFIG_PACKAGE_luci-app-passwall=y
CONFIG_PACKAGE_luci-app-passwall_Nftables_Transparent_Proxy=y
CONFIG_PACKAGE_luci-app-passwall_INCLUDE_ChinaDNS_NG=y
CONFIG_PACKAGE_luci-app-passwall_INCLUDE_Haproxy=y
CONFIG_PACKAGE_luci-app-passwall_INCLUDE_V2ray=y
CONFIG_PACKAGE_luci-app-passwall_INCLUDE_Xray=y
CONFIG_PACKAGE_luci-i18n-passwall-zh-cn=y

一切正常反正。

你这些都是可选的 自然可以不选，限制依赖出在这些 image 这些是没有开关的是必须的基础库，限制l和op 很多都不相同，反正你们慢慢折腾升级吧

WYC-2020 commented 1 year ago

现在只要编译的升级版本 能关的所有都不选，然后保证基础库都有 那就可以升级，升级后在界面上面下载对应的协议内核即可，如果基础库有冲突，在自己确定的情况下可以强制安装，对安装的人有一定的排错能力要求

chunfengyao commented 1 year ago

这玩意基本依赖很多的，搞升级有的你们折腾，因为这些基础依赖是必须的，如果确定没这些也能用，那就强制安装就行了，但是到时候出问题又不知道所以然，到时候又是一堆的issue，并且这些基础依赖很多都和内核版本挂钩，有你们玩的了

passwall项目已经考虑了依赖的缺失问题了，并且，也是支持某些组件的不加载的。 项目中有些地方写的时候就是加了判断是否存在的，另外，编译的时候，也不是所有的组件都是必选组件。 我这边只添加了这几个组件：

CONFIG_PACKAGE_luci-app-passwall=y
CONFIG_PACKAGE_luci-app-passwall_Nftables_Transparent_Proxy=y
CONFIG_PACKAGE_luci-app-passwall_INCLUDE_ChinaDNS_NG=y
CONFIG_PACKAGE_luci-app-passwall_INCLUDE_Haproxy=y
CONFIG_PACKAGE_luci-app-passwall_INCLUDE_V2ray=y
CONFIG_PACKAGE_luci-app-passwall_INCLUDE_Xray=y
CONFIG_PACKAGE_luci-i18n-passwall-zh-cn=y

一切正常反正。

你这些都是可选的 自然可以不选，限制依赖出在这些 image 这些是没有开关的是必须的基础库，限制l和op 很多都不相同，反正你们慢慢折腾升级吧

对，这些是基础库，都是强制依赖的。我说的是packages分支里那些可选库，是不是可以不让luci-app-passwall去依赖。

如果是编译时带了passwall，升级安装的时候，只会提示缺少没选的可选库。

image
WYC-2020 commented 1 year ago

这个让那个打包脚本改下就行的 让它编译 的时候 什么都不选就可以了

nftbty commented 1 year ago

对，这些是基础库，都是强制依赖的。我说的是packages分支里那些可选库，是不是可以不让luci-app-passwall去依赖。

我是很赞同这个想法的，而且我上面也有说其实之前#2118就提交过了，后来因为几个其他小问题revert了。 其实主要的依赖问题反而是这些可选组件，必须的依赖反而是不需要考虑的。因为我是暂时没考虑新装这个问题的。针对的就是已经安装有passwall的用户可以方便升级这个目的。所以这些用户系统上必须依赖都有，只要没有可选组件的依赖，直接安装，任何报错都没有。也想到可能会发生像之前pdnsd改dns2tcp的情况。在考虑整个问题的解决方法的时候，我是把openwrt-passwall-build这个opkg源考虑进去了的，用它的passwall_packages源添加进系统，当luci有添加必须的依赖时，从opkg源安装。 我自己的仓库已经改好了只编译发布passwall的自动编译脚本，没有任何可选依赖，直接安装。不过安装前需要把之前系统上的xray这些需要的插件执行一遍opkg的安装命令让系统将它们标记为手动安装。

nftbty commented 1 year ago

其实可以强制安装的话倒不用这么麻烦，就是有些机器用--nodeps和--force-depends都没法强制安装才需要编译一个干净的的passwall安装包。

我是觉得吧，不管是在更新页面集成更新，还是发布ipk让用户下载升级，总归是要个方便的可以免编译升级的途径。不说好多人不会编译，就是自己会弄的，时间长了也不愿意折腾，也只想安安心心的升级，体验新功能。比如我自己，折腾这段时间，把自更新功能搞好，以后懒得折腾了，也可以随时升级体验新功能。毕竟之前就有过一年多没更新过openwrt。

chunfengyao commented 1 year ago

对，这些是基础库，都是强制依赖的。我说的是packages分支里那些可选库，是不是可以不让luci-app-passwall去依赖。

我是很赞同这个想法的，而且我上面也有说其实之前#2118就提交过了，后来因为几个其他小问题revert了。 其实主要的依赖问题反而是这些可选组件，必须的依赖反而是不需要考虑的。因为我是暂时没考虑新装这个问题的。针对的就是已经安装有passwall的用户可以方便升级这个目的。所以这些用户系统上必须依赖都有，只要没有可选组件的依赖，直接安装，任何报错都没有。也想到可能会发生像之前pdnsd改dns2tcp的情况。在考虑整个问题的解决方法的时候，我是把openwrt-passwall-build这个opkg源考虑进去了的，用它的passwall_packages源添加进系统，当luci有添加必须的依赖时，从opkg源安装。 我自己的仓库已经改好了只编译发布passwall的自动编译脚本，没有任何可选依赖，直接安装。不过安装前需要把之前系统上的xray这些需要的插件执行一遍opkg的安装命令让系统将它们标记为手动安装。

编译的话，可以把step拆开，编译两次，先编译不带任何组件的，然后再编译一次带所有组件的，归档的时候，luci-app-passwall的ipk就使用不带任何组件的那个。或者，干脆弄两条流水线，一条只编译luci-app-passwall，啥组件都不选，另一条就只编译所有组件（两条流水线会多浪费一些资源）。

smallprogram commented 1 year ago

编译已劈叉，release里俩pwd俩ipk，一个全包的，only_luci的

chunfengyao commented 1 year ago

编译已劈叉，release里俩pwd俩ipk，一个全包的，only_luci的

opkg install --force-reinstall luci-app-passwall_4.63_all_only_luci.ipk

可以覆盖升级了，版本号的问题，可以--force-reinstall解决，由于不依赖其它包，所以，--force-reinstall会很顺利。

root@OpenWrt:/tmp# opkg install luci-app-passwall_4.63_all_only_luci.ipk 
Package luci-app-passwall (4.63) installed in root is up to date.
root@OpenWrt:/tmp# opkg install --force-reinstall luci-app-passwall_4.63_all_only_luci.ipk 
Removing package luci-app-passwall from root...
Installing luci-app-passwall (4.63) to root...
Configuring luci-app-passwall.
nftbty commented 1 year ago

可以覆盖升级了，版本号的问题，可以--force-reinstall解决，由于不依赖其它包，所以，--force-reinstall会很顺利。

那你之前的版本是自己编译的吗？如果是编译时选择的Xray之类的插件，再用无依赖版安装，应该会自动移除啊。我之前有次升级忘了这回事，一升级，导致全部插件都被移除了。 这一点确实需要注意，我仓库自动编译发布的，都加了提示，需要先对插件执行一次手动安装命令。不知道还有没有什么更好的方法规避这个问题（当然最彻底的办法是把makefile里对插件的依赖改为select选中）。 对了，我仓库发布的ipk是使用21.02版SDK+19.07版luci编译的，版本号是完整的4.63-5这样的。

chunfengyao commented 1 year ago

可以覆盖升级了，版本号的问题，可以--force-reinstall解决，由于不依赖其它包，所以，--force-reinstall会很顺利。

那你之前的版本是自己编译的吗？如果是编译时选择的Xray之类的插件，再用无依赖版安装，应该会自动移除啊。我之前有次升级忘了这回事，一升级，导致全部插件都被移除了。 这一点确实需要注意，我仓库自动编译发布的，都加了提示，需要先对插件执行一次手动安装命令。不知道还有没有什么更好的方法规避这个问题（当然最彻底的办法是把makefile里对插件的依赖改为select选中）。 对了，我仓库发布的ipk是使用21.02版SDK+19.07版luci编译的，版本号是完整的4.63-5这样的。

我是直接添加passwall到feeds中，选了部分组件，一起编译的。按照--force-reinstall的逻辑，他应该只检测了待安装的ipk的依赖。由于_only_luci.ipk依赖组件都移除了，所以--force-reinstall没有去移除之前依赖的组件。之前那个所有组件都选了的版本，--force-reinstall确实会移除所有组件。

nftbty commented 1 year ago

我是直接添加passwall到feeds中，选了部分组件，一起编译的。按照--force-reinstall的逻辑，他应该只检测了待安装的ipk的依赖。由于_only_luci.ipk依赖组件都移除了，所以--force-reinstall没有去移除之前依赖的组件。之前那个所有组件都选了的版本，--force-reinstall确实会移除所有组件。

假设之前编译系统时选了passwall 的所有组件，然后现在从release下载了passwall新版的ipk要升级，那么是否使用--force-reinstall，还有安装全依赖版还是无依赖版，共有4种组合：

  1. 直接安装，全依赖版 -> 没问题✅
  2. 直接安装，无依赖版 -> 组件全被移除
  3. 强制重装，全依赖版 -> 按你的说法，应该会移除所有组件，再安装新版，但新版有依赖，又没法自动下载，会安装失败？ 通过下面对源码的分析，只要使用force-reinstall安装，就不会移除依赖的组件，跟安装的ipk是什么依赖无关。当然，如果旧版本只有少数几个依赖，装全依赖的新版，还是会有依赖问题，
  4. 强制重装，无依赖版 -> 不会移除组件✅

查看一下opkg的源码，来验证这几个问题。

if (conf->force_reinstall) {
    int saved_force_depends = conf->force_depends;
    conf->force_depends = 1;
    (void)opkg_remove_cmd(argc, argv);
    conf->force_depends = saved_force_depends;
    conf->force_reinstall = 0;
}

这里就是先使用force-depends参数移除之前安装的版本，然后又查了下force-depends移除pkg时的行为，

/* only attempt to remove dependent installed packages if
 * force_depends is not specified or the package is being
 * replaced.
 */
if (!conf->force_depends && !(pkg->state_flag & SF_REPLACE)) {
    ......
}

代码都不用看了，注释都说明了，只有未指定使用force-depends参数时，才会移除该pkg依赖的pkgs。

然后看了下install时自动移除依赖的部分

/*
 * Remove packages which were auto_installed due to a dependency by old_pkg,
 * which are no longer a dependency in the new (upgraded) pkg.
 */
static int pkg_remove_orphan_dependent(pkg_t * pkg, pkg_t * old_pkg)
{
}

这个函数里面并没有任何参数可以跳过这个过程，除非这个包不是auto_installed的。 这样看来，使用force-reinstall确实是一个简单的解决办法。当然更稳妥的还是想办法让系统把需要的组件标记为手动安装的，也不知道之前想的手动执行一次安装命令的方法是否可行，进一步查看。 好吧，opkg并没有跟apt一样的功能，自动安装的标记没法改手动的，反倒是根据这一处

if (!oldpkg->auto_installed)
    oldpkg->auto_installed = newpkg->auto_installed;

貌似可以把非自动安装改自动安装，但是没仔细研究代码，不清楚这是什么情况下使用的。

总结：旧版带组件依赖的版本，使用无组件依赖版本安装，只能使用--force-reinstall安装，或者先用--force-depends移除旧版再正常安装新版。

chunfengyao commented 1 year ago

我是直接添加passwall到feeds中，选了部分组件，一起编译的。按照--force-reinstall的逻辑，他应该只检测了待安装的ipk的依赖。由于_only_luci.ipk依赖组件都移除了，所以--force-reinstall没有去移除之前依赖的组件。之前那个所有组件都选了的版本，--force-reinstall确实会移除所有组件。

假设之前编译系统时选了passwall 的所有组件，然后现在从release下载了passwall新版的ipk要升级，那么是否使用--force-reinstall，还有安装全依赖版还是无依赖版，共有4种组合：

  1. 直接安装，全依赖版 -> 没问题✅
  2. 直接安装，无依赖版 -> 组件全被移除
  3. 强制重装，全依赖版 -> ~按你的说法，应该会移除所有组件，再安装新版，但新版有依赖，又没法自动下载，会安装失败？~ 通过下面对源码的分析，只要使用force-reinstall安装，就不会移除依赖的组件，跟安装的ipk是什么依赖无关。当然，如果旧版本只有少数几个依赖，装全依赖的新版，还是会有依赖问题，
  4. 强制重装，无依赖版 -> 不会移除组件✅

查看一下opkg的源码，来验证这几个问题。

if (conf->force_reinstall) {
  int saved_force_depends = conf->force_depends;
  conf->force_depends = 1;
  (void)opkg_remove_cmd(argc, argv);
  conf->force_depends = saved_force_depends;
  conf->force_reinstall = 0;
}

这里就是先使用force-depends参数移除之前安装的版本，然后又查了下force-depends移除pkg时的行为，

/* only attempt to remove dependent installed packages if
 * force_depends is not specified or the package is being
 * replaced.
 */
if (!conf->force_depends && !(pkg->state_flag & SF_REPLACE)) {
  ......
}

代码都不用看了，注释都说明了，只有未指定使用force-depends参数时，才会移除该pkg依赖的pkgs。

然后看了下install时自动移除依赖的部分

/*
 * Remove packages which were auto_installed due to a dependency by old_pkg,
 * which are no longer a dependency in the new (upgraded) pkg.
 */
static int pkg_remove_orphan_dependent(pkg_t * pkg, pkg_t * old_pkg)
{
}

这个函数里面并没有任何参数可以跳过这个过程，除非这个包不是auto_installed的。 这样看来，使用force-reinstall确实是一个简单的解决办法。当然更稳妥的还是想办法让系统把需要的组件标记为手动安装的，也不知道之前想的手动执行一次安装命令的方法是否可行，进一步查看。 好吧，opkg并没有跟apt一样的功能，自动安装的标记没法改手动的，反倒是根据这一处

if (!oldpkg->auto_installed)
  oldpkg->auto_installed = newpkg->auto_installed;

貌似可以把非自动安装改自动安装，但是没仔细研究代码，不清楚这是什么情况下使用的。

总结：旧版带组件依赖的版本，使用无组件依赖版本安装，只能使用--force-reinstall安装，或者先用--force-depends移除旧版再正常安装新版。

--force-reinstall，只会校验当前ipk需要的依赖是不是存在，且版本号高于或等于需要的版本，只要满足条件，就行，并不会去影响已安装的其它软件包。如果不满足（比如有缺失，或者版本号低），就会直接报缺少依赖。如果满足，就先忽略依赖移除当前ipk对应的那个旧版本软件包，然后忽略依赖安装当前的ipk。

WROIATE commented 1 year ago

@nftbty 使用only安装包还是失败，是因为使用的是lean lede的缘故吗

image
nftbty commented 1 year ago

@nftbty 使用only安装包还是失败，是因为使用的是lean lede的缘故吗 image

这个自动编译使用的luci是master版，已经全面转向ucode，旧版lua只为了兼容性考虑而保留，所以对于使用新版luci编译的旧版luci app，会加上这么一个luci-lua-runtime的依赖，你看看再加上--force-depends或者--nodeps能不能装。或者直接去我的仓库release下载，我是用19.07版luci编译的，使用--force-reinstall安装就行了。找最下面的4.63-5，上面的其他版本是我在测试自动编译，不过编译的其实也是4.63-5的。

WROIATE commented 1 year ago

@nftbty 我这边--force-depends和--nodeps均无效，看起来就是不兼容老版luci，可以在release中提示下

image image
nftbty commented 1 year ago

@nftbty 我这边--force-depends和--nodeps均无效，看起来就是不兼容老版luci，可以在release中提示下

那你从我的仓库下吧，肯定可以装上。 我的也是lean op，之前测试--nodeps和--foece-depends无效，不知道是不是opkg版本的问题。

chunfengyao commented 1 year ago

@nftbty 使用only安装包还是失败，是因为使用的是lean lede的缘故吗 image

你这是用22.03.3作为基础镜像的吗？ 最新的tag对应的Actions里面编译的好像是snapshot分支的镜像，之前一个tag使用的22.03.3分支的Actions是不包含luci-lua-runtime这个依赖的。我用最新的tag编译的产物，也装不上了。

chunfengyao commented 1 year ago

@nftbty 使用only安装包还是失败，是因为使用的是lean lede的缘故吗 image

你这是用22.03.3作为基础镜像的吗？ 最新的tag对应的Actions里面编译的好像是snapshot分支的镜像，之前一个tag使用的22.03.3分支的Actions是不包含luci-lua-runtime这个依赖的。我用最新的tag编译的产物，也装不上了。

有个可以尝试的解决方案。这个方法原先是用来修改软件包的版本号用的。

修改软件的版本信息：

# 查询:
opkg -V info luci-app-passwall
# 修改:
vi /usr/lib/opkg/status
vi /usr/lib/opkg/info/luci-app-passwall.control
# 查询修改结果:
opkg -V info luci-app-passwall

可以通过修改这两个文件，添加假的luci-lua-runtime，让系统认为已经安装过luci-lua-runtime了。然后再--force-reinstall，可能可以绕过这个报错。

chunfengyao commented 1 year ago

luci-lua-runtime in luci-openwrt-22.03, 404 Not Found

luci-lua-runtime in luci-master

原以为最近新发的22.03.3会有这个luci-lua-runtime，这个包好像还没进入22.03的分支。可能只有snapshot分支上有。

是不是可以考虑使用22.03.3的OpenWrtsdk？或者，这个luci-lua-runtime是不是可以编译时排除掉？

nftbty commented 1 year ago

luci-lua-runtime in luci-openwrt-22.03

luci-lua-runtime in luci-master

原以为最近新发的22.03.3会有这个luci-lua-runtime，这个包好像还没进入22.03的分支。可能只有snapshot分支上有。

是不是可以考虑使用22.03.3的OpenWrtsdk？或者，这个luci-lua-runtime是不是可以编译时排除掉？

这个问题，就在本issue的前面一点，我前几天有发过原因。 https://github.com/xiaorouji/openwrt-passwall/issues/2464#issuecomment-1499250452 https://github.com/xiaorouji/openwrt-passwall/issues/2464#issuecomment-1499923014

另外，刚刚翻了一下，这个自动编译一开始就是有的处理器用的22.03.3，有的用的snapshot，然后开始没有把luci单独上传，需要下载任一架构的压缩包解压ipk安装。后来我提了一下，把passwall的ipk单独列出来了，不过这个是不固定的，最终下载到的版本，是最后编译完上传的那个，根据我这两天多次测试无意中发现，好像使用snapshot版SDK的编译要慢得多，所以，估计最后的luci其实是x86_64编译的，刚好用的snapshot。 我已经提交了一部分优化 #2484，无依赖版luci使用21.02版SDK+19.07版luci源，另外使用了缓存。如果合并了，以后每次更新版本号，3分钟以内就可以下载到新版的ipk了。 当然，目前这种以处理器型号而不是架构来区分的编译不是很合理，因为很多架构重复的。比如7620/7621都是mipsel_24kc，还有好几个都是mips_24kc的，等等。我打算修改成使用openwrt发布的sdk docker来编译，这个可以直接根据处理器架构拉取相应SDK镜像。