IceCodeNew

我之前没接触过 GitHub Action，不过看懂 .github/workflows/go.yml 要求干了什么操作还是没问题的。 我觉得现在的 Action 或许应该考虑加入“上次 Action 所用的数据库文件到这次 Action 之间是否发生过更新”的检查，或者直接改为每周运作一次。 官方网站上对 GeoLite2 数据库已经说的很明白了，每周才更新一次（具体是哪个时区的周二暂且不清楚），不过也足够说明现在每天 build 一个新的 geoip.dat 文件出来有点欠考虑了。 > The GeoLite2 Country, City, and ASN databases are updated weekly,...

> 比如AutoBreak就是你说的换行的问题的开关。 感谢建议 --- > 目前还没有一个一键开关来支持GFM。 嗯，这也是我开这个功能建议的原因。感觉遵循 GFM 还是能避免不少切换渲染引擎时的问题。

> Also, query path should be encapsulated inside the TLS stream with DoH, so I don't think the query path should matter. Can you expand on that? Well, I'm not...

a). 尽管对于所有安装场景，本项目都会添加 drop-in 配置，但这个配置在用户没有设置环境变量进行自定义时，是和发行版包文件里内容一致的。 b). 安装过程中有特意强调出来的提示告知用户检查 drop-in 配置是否符合需要 https://github.com/v2fly/fhs-install-v2ray/blob/804e5e3788a6770b3111f9ad01dd81101b0997d4/install-release.sh#L356-L380 cons on a): 如果更新不及时，就会给不打算自定义安装参数的用户带去困扰。 但其实这里设计时我也头疼过很久，最开始我是判断环境变量是否存在，如果存在是否与项目默认安装位置相等，结合两个判断才去创建 drop-in 配置。但后来一想，发现如果上游改变默认安装位置，但不提前通知本项目的维护成员，那同样会发生在不必要创建 drop-in 配置时创建 drop-in 配置的情况。 所以最后就挑最简单的来实现了，但是提前在安装时给足用户提示。

你说到 systemd 配置应该和其他发行版包文件保持一致，其实这里是做到了的才对。 从实际出发，上游不定时改变 systemd 配置文件这一点是本项目应该预期的。所以有必要在安装时更新已经存在的 systemd 配置文件。 但是这样一来很多用户选择自定义 systemd 配置文件的，又会遇到每次使用脚本升级都丢失自己修改的问题。 我确实认为这两个问题都是本项目必须解决的问题，而且认为同时解决这两个问题非 drop-in 配置不可。如果你有更好的提议，欢迎告诉我。

> 如果是为了提示，为什么不直接把 systemd 文件打印出来呢 你再往下面多读几行……

> 能否加一个 --keep-service-file 参数，当带有这个参数运行的时候会跳过install_startup_service_file() 这个函数？ 可。

> I still think the install script should act the way all (or at least most) install script on Linux do: > > * Test if an existing service file...

> 反正我每次更新前，都把先找出我之前修改好的v2ray.service > > ```ini > [Unit] > Description=V2Ray Service > Documentation=https://www.v2fly.org/ > After=network.target nss-lookup.target > > [Service] > User=nobody > CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE > AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE > NoNewPrivileges=true > ExecStart=/usr/local/bin/v2ray...

@unknowndev233 看看 PR #114 对于解决这个问题是不是足够。