避免覆盖xray的服务

[wangling12]

这种覆盖会导致我在opkg单独升级xray的时候,服务文件被xray的覆盖掉.....有点坑啊

看了一圈,我想改的地方 @ttimasdf 这老哥已经实现了https://github.com/ttimasdf/luci-app-xray/commit/1c64892d8b2f22573da52a2c44a0e9694c9e6e5e 然后为了避免重复造轮子,希望 @ttimasdf 老哥往这里合并一下,然后考虑以同一个仓库往官方仓库提交如何?

[yichya]

近期会打算把这个项目拆成 fw3 和 fw4 两个版本，到时候配置文件、init 都分别用 xray_fw3 xray_fw4 区分开（主要是 xray_fw3 应该不会再维护很久了），不会再跟 OpenWrt Packages 自带的 Xray 冲突。

[hqvv]

支持出个纯 fw4 版本

[ttimasdf]

这种覆盖会导致我在opkg单独升级xray的时候,服务文件被xray的覆盖掉.....有点坑啊

看了一圈,我想改的地方 @ttimasdf 这老哥已经实现了ttimasdf/luci-app-xray@1c64892 然后为了避免重复造轮子,希望 @ttimasdf 老哥往这里合并一下,然后考虑以同一个仓库往官方仓库提交如何?

我的项目以前是个 fork，后来找客服提工单从 network 里分出去了，目前和以后均不考虑 PR，以前 其实提过一些PR 但自己维护分支自由度比较高一些，代码质量也比较可控。比如说，我前面 PR 的东西（#69），后面就被 revert 掉了（ https://github.com/yichya/luci-app-xray/commit/84f05d9a93be3d0df0489e20a1237e997221b045 ）

其实我也在想fw3的问题，目前在解决 #70 #72 的问题，等这个feature加上去估计就会跨个大版本号然后把fw3支持drop掉了😛

如果要考虑 fw3 fw4 兼容问题的话，我的解决方案是在安装时检测下环境，做个判断，这样以后虽然不加功能了，luci上再加功能也不会崩。

在opkg install时设置flag： Makefile#L93-L108 , xray.js#L13-L18

在luci里读取flag：xray.js#L47