mihomo
mihomo copied to clipboard
MetaCubeX
[Feature] 关于龙架构二进制文件名的建议
Verify steps
- [X] 我已经在 Issue Tracker 中找过我要提出的请求 I have searched on the issue tracker for a related feature request.
- [X] 我已经仔细看过 Documentation 并无法找到这个功能 I have read the documentation and was unable to solve the issue.
Description
现在mihomo已经同时支持龙架构的新世界和旧世界并且提供二进制了，但是二进制的文件名不是很优雅。比如新世界的deb包叫 mihomo-linux-loong64-abi2-v1.18.2.deb ，旧世界的deb包叫 mihomo-linux-loong64-abi1-v1.18.2.deb ，比其他架构多出来个abi1和abi2，丑，并且在编译clash-verge-rev的时候会带来一些问题，需要改代码。所以建议改名。 目前，新世界和旧世界发行版的命名规则是有不同的，新世界的架构名为loong64，旧世界为loongarch64。 按照这个规则，建议把旧世界文件名 mihomo-linux-loong64-abi1-v1.18.2.deb 改为 mihomo-linux-loongarch64-v1.18.2.deb ，把新世界文件名 mihomo-linux-loong64-abi2-v1.18.2.deb 改为 mihomo-linux-loong64-v1.18.2.deb 。这样，就和其他架构统一了，玩龙芯的也能一眼看出来哪个是新世界的二进制，哪个是旧世界的二进制。
Possible Solution
建议把旧世界文件名 mihomo-linux-loong64-abi1-v1.18.2.deb 改为 mihomo-linux-loongarch64-v1.18.2.deb ，把新世界文件名 mihomo-linux-loong64-abi2-v1.18.2.deb 改为 mihomo-linux-loong64-v1.18.2.deb 。 把旧世界文件名 mihomo-linux-loong64-abi1-alpha-0b4662e.deb 改为 mihomo-linux-loongarch64-alpha-0b4662e.deb ，把新世界文件名 mihomo-linux-loong64-abi2-alpha-0b4662e.gz 改为 mihomo-linux-loong64-alpha-0b4662e.gz 。
@LinuxResearcher loongarch64和loong64的区分不够清晰,不如abi1/2
的确，abi1/2非常清晰。主要是龙架构旧世界的软件包架构名都是loongarch64，新架构都是loong64。关于这一点，龙芯用户是能区分的，其他用户无需关注。其他架构都不带abi1/2，龙架构的带着很不顺眼啊。
@LinuxResearcher loongarch64和loong64的区分不够清晰,不如abi1/2
的确，abi1/2非常清晰。主要是龙架构旧世界的软件包架构名都是loongarch64，新架构都是loong64。关于这一点，龙芯用户是能区分的，其他用户无需关注。其他架构都不带abi1/2，龙架构的带着很不顺眼啊。
并不是所有的新世界架构名都是loong64，还有部分新世界的发行版依然采用龙芯官方的loongarch64的架构命名，怎么不说新世界的deb包叫 mihomo-linux-loongarch64-abi2-v1.18.2.deb ，旧世界的deb包叫 mihomo-linux-loongarch64-abi1-v1.18.2.deb😏
@LinuxResearcher loongarch64和loong64的区分不够清晰,不如abi1/2
大大，可以考虑一下按照龙芯官方的loongarch64-abi1和loongarch64-abi2命名法进行命名吗？
@LinuxResearcher loongarch64和loong64的区分不够清晰,不如abi1/2
的确，abi1/2非常清晰。主要是龙架构旧世界的软件包架构名都是loongarch64，新架构都是loong64。关于这一点，龙芯用户是能区分的，其他用户无需关注。其他架构都不带abi1/2，龙架构的带着很不顺眼啊。
并不是所有的新世界架构名都是loong64，还有部分新世界的发行版依然采用龙芯官方的loongarch64的架构命名，怎么不说新世界的deb包叫 mihomo-linux-loongarch64-abi2-v1.18.2.deb ，旧世界的deb包叫 mihomo-linux-loongarch64-abi1-v1.18.2.deb😏
新世界叫loongarch64的只有AOSC OS一家，叫loong64是Debian的约定，其他发行版都遵守这个约定了。
@LinuxResearcher loongarch64和loong64的区分不够清晰,不如abi1/2
的确，abi1/2非常清晰。主要是龙架构旧世界的软件包架构名都是loongarch64，新架构都是loong64。关于这一点，龙芯用户是能区分的，其他用户无需关注。其他架构都不带abi1/2，龙架构的带着很不顺眼啊。
并不是所有的新世界架构名都是loong64，还有部分新世界的发行版依然采用龙芯官方的loongarch64的架构命名，怎么不说新世界的deb包叫 mihomo-linux-loongarch64-abi2-v1.18.2.deb ，旧世界的deb包叫 mihomo-linux-loongarch64-abi1-v1.18.2.deb😏
新世界叫loongarch64的只有AOSC OS一家，叫loong64是Debian的约定，其他发行版都遵守这个约定了。
这倒是，目前只有 AOSC OS 和 RPM 系均采用全称 loongarch64 的命名，其他的则是采用 loong 或 loong64 命名
@LinuxResearcher loongarch64和loong64的区分不够清晰,不如abi1/2
的确，abi1/2非常清晰。主要是龙架构旧世界的软件包架构名都是loongarch64，新架构都是loong64。关于这一点，龙芯用户是能区分的，其他用户无需关注。其他架构都不带abi1/2，龙架构的带着很不顺眼啊。
并不是所有的新世界架构名都是loong64，还有部分新世界的发行版依然采用龙芯官方的loongarch64的架构命名，怎么不说新世界的deb包叫 mihomo-linux-loongarch64-abi2-v1.18.2.deb ，旧世界的deb包叫 mihomo-linux-loongarch64-abi1-v1.18.2.deb😏
新世界叫loongarch64的只有AOSC OS一家，叫loong64是Debian的约定，其他发行版都遵守这个约定了。
有个不成熟的想法，能否把文件名用全称loongarch64-abi1/2来区分，然后在新世界中的control文件里把loong、loong64、loongarch64这几个架构名都同时加上呢？
@LinuxResearcher loongarch64和loong64的区分不够清晰,不如abi1/2
的确，abi1/2非常清晰。主要是龙架构旧世界的软件包架构名都是loongarch64，新架构都是loong64。关于这一点，龙芯用户是能区分的，其他用户无需关注。其他架构都不带abi1/2，龙架构的带着很不顺眼啊。
并不是所有的新世界架构名都是loong64，还有部分新世界的发行版依然采用龙芯官方的loongarch64的架构命名，怎么不说新世界的deb包叫 mihomo-linux-loongarch64-abi2-v1.18.2.deb ，旧世界的deb包叫 mihomo-linux-loongarch64-abi1-v1.18.2.deb😏
新世界叫loongarch64的只有AOSC OS一家，叫loong64是Debian的约定，其他发行版都遵守这个约定了。
有个不成熟的想法，能否把文件名用全称loongarch64-abi1/2来区分，然后在新世界中的control文件里把loong、loong64、loongarch64这几个架构名都同时加上呢？
你这真是不成熟的想法。为什么一定要叫loongarch64？因为loongnix这样叫吗？实际上，龙架构的架构名是龙，也就是loong，最多在loong后面加上32或者64表示位数。叫loongarch64，第一太长，第二表达上有重复（龙架构架构）。这种重复的表达不觉得很傻屄吗？架构名后面带arch的只有arm（rpm系的aarch64），还仅限于rpm系，并且也对arm进行了缩写。哦，还有个ia64，是intel architecture的缩写，不过人家缩写了，当然现在这个架构已经没有了。现存的其他的架构名，amd64、ppc64、mips64el、x86_64、rv64、arm64、sw64等等，哪个傻屄到命名为amdarch64、ppcarch64、mipsarch64el、x86arch_64、rvarch64、armarch64、swarch64？ loongnix架构名为loongarch64，大概率是为了体现出来loongarch是龙芯中科的商标，其实这种命名很傻屄。
@LinuxResearcher loongarch64和loong64的区分不够清晰,不如abi1/2
的确，abi1/2非常清晰。主要是龙架构旧世界的软件包架构名都是loongarch64，新架构都是loong64。关于这一点，龙芯用户是能区分的，其他用户无需关注。其他架构都不带abi1/2，龙架构的带着很不顺眼啊。
并不是所有的新世界架构名都是loong64，还有部分新世界的发行版依然采用龙芯官方的loongarch64的架构命名，怎么不说新世界的deb包叫 mihomo-linux-loongarch64-abi2-v1.18.2.deb ，旧世界的deb包叫 mihomo-linux-loongarch64-abi1-v1.18.2.deb😏
新世界叫loongarch64的只有AOSC OS一家，叫loong64是Debian的约定，其他发行版都遵守这个约定了。
有个不成熟的想法，能否把文件名用全称loongarch64-abi1/2来区分，然后在新世界中的control文件里把loong、loong64、loongarch64这几个架构名都同时加上呢？
你这真是不成熟的想法。为什么一定要叫loongarch64？因为loongnix这样叫吗？实际上，龙架构的架构名是龙，也就是loong，最多在loong后面加上32或者64表示位数。叫loongarch64，第一太长，第二表达上有重复（龙架构架构）。这种重复的表达不觉得很傻屄吗？架构名后面带arch的只有arm（rpm系的aarch64），还仅限于rpm系，并且也对arm进行了缩写。哦，还有个ia64，是intel architecture的缩写，不过人家缩写了，当然现在这个架构已经没有了。现存的其他的架构名，amd64、ppc64、mips64el、x86_64、rv64、arm64、sw64等等，哪个傻屄到命名为amdarch64、ppcarch64、mipsarch64el、x86arch_64、rvarch64、armarch64、swarch64？ loongnix架构名为loongarch64，大概率是为了体现出来loongarch是龙芯中科的商标，其实这种命名很傻屄。
但是已经有 loongson2f 与 loongson3 两个架构名了，再用 loong64 不会觉得……。
@LinuxResearcher loongarch64和loong64的区分不够清晰,不如abi1/2
的确，abi1/2非常清晰。主要是龙架构旧世界的软件包架构名都是loongarch64，新架构都是loong64。关于这一点，龙芯用户是能区分的，其他用户无需关注。其他架构都不带abi1/2，龙架构的带着很不顺眼啊。
并不是所有的新世界架构名都是loong64，还有部分新世界的发行版依然采用龙芯官方的loongarch64的架构命名，怎么不说新世界的deb包叫 mihomo-linux-loongarch64-abi2-v1.18.2.deb ，旧世界的deb包叫 mihomo-linux-loongarch64-abi1-v1.18.2.deb😏
新世界叫loongarch64的只有AOSC OS一家，叫loong64是Debian的约定，其他发行版都遵守这个约定了。
有个不成熟的想法，能否把文件名用全称loongarch64-abi1/2来区分，然后在新世界中的control文件里把loong、loong64、loongarch64这几个架构名都同时加上呢？
你这真是不成熟的想法。为什么一定要叫loongarch64？因为loongnix这样叫吗？实际上，龙架构的架构名是龙，也就是loong，最多在loong后面加上32或者64表示位数。叫loongarch64，第一太长，第二表达上有重复（龙架构架构）。这种重复的表达不觉得很傻屄吗？架构名后面带arch的只有arm（rpm系的aarch64），还仅限于rpm系，并且也对arm进行了缩写。哦，还有个ia64，是intel architecture的缩写，不过人家缩写了，当然现在这个架构已经没有了。现存的其他的架构名，amd64、ppc64、mips64el、x86_64、rv64、arm64、sw64等等，哪个傻屄到命名为amdarch64、ppcarch64、mipsarch64el、x86arch_64、rvarch64、armarch64、swarch64？ loongnix架构名为loongarch64，大概率是为了体现出来loongarch是龙芯中科的商标，其实这种命名很傻屄。
但是已经有 loongson2f 与 loongson3 两个架构名了，再用 loong64 不会觉得……。
loongson2f是处理器的名字，loongson3也是，在gcc里面是cpu类型，不是软件包名里面的架构名。loongson2f的架构名是mipsel，loongson3是mips64el。
这个命名规则，龙芯那边有官方文档来约束没？
目前没有，现在只有默认的做法，并且已经开始混乱了。
不过，可以确定的是，所有旧世界架构名都是loongarch64。而新世界这方面，debian是发行版的重要标准参考，debian是把架构名定为loong64的，已经进dpkg上游了。更早的gentoo也是loong64，龙芯官方的新世界发行版LoongArchLinux也是loong64。 https://wiki.debian.org/Ports/loong64 https://wiki.debian.org/LoongArch
这个命名规则，龙芯那边有官方文档来约束没？
目前没有，现在只有默认的做法，并且已经开始混乱了。
不过，可以确定的是，所有旧世界架构名都是loongarch64。而新世界这方面，debian是发行版的重要标准参考，debian是把架构名定为loong64的，已经进dpkg上游了。更早的gentoo也是loong64，龙芯官方的新世界发行版LoongArchLinux也是loong64。 https://wiki.debian.org/Ports/loong64 https://wiki.debian.org/LoongArch
http://mirrors.tencent.com/loongson/install/
这个命名规则，龙芯那边有官方文档来约束没？
目前没有，现在只有默认的做法，并且已经开始混乱了。 不过，可以确定的是，所有旧世界架构名都是loongarch64。而新世界这方面，debian是发行版的重要标准参考，debian是把架构名定为loong64的，已经进dpkg上游了。更早的gentoo也是loong64，龙芯官方的新世界发行版LoongArchLinux也是loong64。 https://wiki.debian.org/Ports/loong64 https://wiki.debian.org/LoongArch
http://mirrors.tencent.com/loongson/install/
这个目录是刘工移植的龙芯2F安装方式，刘工自己打包的debian系统。这个loongarch64是刘工起的文件名，架构名还是loong64。不信你安装上去看看，里面的软件包是不是带loong64后缀。还有，这里的软件包全部来自http://ftp.ports.debian.org/debian-ports/pool-loong64/main/
这个命名规则，龙芯那边有官方文档来约束没？
目前没有，现在只有默认的做法，并且已经开始混乱了。
不过，可以确定的是，所有旧世界架构名都是loongarch64。而新世界这方面，debian是发行版的重要标准参考，debian是把架构名定为loong64的，已经进dpkg上游了。更早的gentoo也是loong64，龙芯官方的新世界发行版LoongArchLinux也是loong64。 https://wiki.debian.org/Ports/loong64 https://wiki.debian.org/LoongArch
官方不说话，那就一定会混乱了。
这个命名规则，龙芯那边有官方文档来约束没？
目前没有，现在只有默认的做法，并且已经开始混乱了。 不过，可以确定的是，所有旧世界架构名都是loongarch64。而新世界这方面，debian是发行版的重要标准参考，debian是把架构名定为loong64的，已经进dpkg上游了。更早的gentoo也是loong64，龙芯官方的新世界发行版LoongArchLinux也是loong64。 https://wiki.debian.org/Ports/loong64 https://wiki.debian.org/LoongArch
官方不说话，那就一定会混乱了。
这个混乱，问题不大，因为发行版本来就是包不能互相安装的。但是，起码rpm和deb得分别对应起来。新世界的rpm都是loongarch64，好像rpm喜欢用cpu的架构名作为包架构名，并且喜欢和商标一致。
强烈请求支持新世界的的命名： mihomo-linux-loong64-alpha-0b4662e.gz 如果需要保留abi的写法，可以单独添加一个上面名称的包。
- loong64是主流的新世界叫法，毋庸置疑了。没有讨论的余地了。
- 旧世界将缓慢淘汰。
- mihomo作为上游包，被下游依赖。小改动可能会影响很大，希望慎重，不要留下历史包袱和遗憾。
- 许多下游包遵循了默认的命名格式，抓mihomo。如（clash-verge） abi格式的抓不到，干脆先单独加个经典格式的loong64包，稳定下游，再慢慢讨论。
目前龙芯官方还未在新世界中提供显卡驱动，所以旧世界也还会在未来存在一段时间。
况且新旧世界的区分从来就不是用loong64和loongarch64进行区分，而是通过abi1/abi2进行区分，这点龙芯有说到过。
---原始邮件--- 发件人: @.> 发送时间: 2024年4月25日(周四) 晚上10:35 收件人: @.>; 抄送: @.@.>; 主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)
强烈请求支持新世界的的命名： mihomo-linux-loong64-alpha-0b4662e.gz 如果需要保留abi的写法，可以单独添加一个上面名称的包。
loong64是主流的新世界叫法，毋庸置疑了。没有讨论的余地了。
旧世界将缓慢淘汰。
mihomo作为上游包，被下游依赖。小改动可能会影响很大，希望慎重，不要留下历史包袱和遗憾。
许多下游包遵循了默认的命名格式，抓mihomo。如（clash-verge） abi格式的抓不到，干脆先单独加个经典格式的loong64包，稳定下游，再慢慢讨论。
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
目前龙芯官方还未在新世界中提供显卡驱动，所以旧世界也还会在未来存在一段时间。 况且新旧世界的区分从来就不是用loong64和loongarch64进行区分，而是通过abi1/abi2进行区分，这点龙芯有说到过。 … ---原始邮件--- 发件人: @.> 发送时间: 2024年4月25日(周四) 晚上10:35 收件人: @.>; 抄送: @.@.>; 主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141) 强烈请求支持新世界的的命名： mihomo-linux-loong64-alpha-0b4662e.gz 如果需要保留abi的写法，可以单独添加一个上面名称的包。 loong64是主流的新世界叫法，毋庸置疑了。没有讨论的余地了。 旧世界将缓慢淘汰。 mihomo作为上游包，被下游依赖。小改动可能会影响很大，希望慎重，不要留下历史包袱和遗憾。 许多下游包遵循了默认的命名格式，抓mihomo。如（clash-verge） abi格式的抓不到，干脆先单独加个经典格式的loong64包，稳定下游，再慢慢讨论。 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
现在不是说，龙芯定啥标准，社区就怎么去干。
- 现在的既定事实是社区广泛支持loong64命名。
- 开源/自由软件社区主要就是为新世界打包的，是去适配新世界的。
- 用loong64的命名方案已经是主流的支持了，简洁优雅
如果非要辩论很久，完全可以考虑单独提供mihomo-linux-loong64-alpha-0b4662e.gz命名的包，和其他的并存。
明明是很容易能做到 简洁，优雅，一致的事情， 真不至于
跑开龙芯不谈是不是就有点过河拆桥卸磨杀驴了？那么龙芯定的标准还有什么意思？
---原始邮件--- 发件人: @.> 发送时间: 2024年4月25日(周四) 晚上11:18 收件人: @.>; 抄送: @.@.>; 主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)
目前龙芯官方还未在新世界中提供显卡驱动，所以旧世界也还会在未来存在一段时间。 况且新旧世界的区分从来就不是用loong64和loongarch64进行区分，而是通过abi1/abi2进行区分，这点龙芯有说到过。 … ---原始邮件--- 发件人: @.> 发送时间: 2024年4月25日(周四) 晚上10:35 收件人: @.>; 抄送: @.@.>; 主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141) 强烈请求支持新世界的的命名： mihomo-linux-loong64-alpha-0b4662e.gz 如果需要保留abi的写法，可以单独添加一个上面名称的包。 loong64是主流的新世界叫法，毋庸置疑了。没有讨论的余地了。 旧世界将缓慢淘汰。 mihomo作为上游包，被下游依赖。小改动可能会影响很大，希望慎重，不要留下历史包袱和遗憾。 许多下游包遵循了默认的命名格式，抓mihomo。如（clash-verge） abi格式的抓不到，干脆先单独加个经典格式的loong64包，稳定下游，再慢慢讨论。 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
现在不是说，龙芯定啥标准，社区就怎么去干。
现在的既定事实是社区广泛支持loong64命名。
开源/自由软件社区主要就是为新世界打包的，是去适配新世界的。
用loong64的命名方案已经是主流的支持了，简洁优雅
如果非要辩论很久，完全可以考虑单独提供mihomo-linux-loong64-alpha-0b4662e.gz命名的包，和其他的并存。
明明是很容易能做到 简洁，优雅，一致的事情， 真不至于
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
对于社区，龙芯的标准好，就采用，不好，就不采用。
对于龙芯： “只要你说的对，我们就改正，只要你说的对人民有好处，我们就照你说的办”
loong64已经是板上钉钉了，没有讨论余地了。 本来就是试错改错的过程，没必要一条路走到底
但是AOSC也还在使用loongarch64作为架构名，社区并不只有debian，这两个也都是根社区，并且使用AOSC的人也并不少
---原始邮件--- 发件人: @.> 发送时间: 2024年4月25日(周四) 晚上11:39 收件人: @.>; 抄送: @.@.>; 主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)
对于社区，龙芯的标准好，就采用，不好，就不采用。
对于龙芯： “只要你说的对，我们就改正，只要你说的对人民有好处，我们就照你说的办”
loong64已经是板上钉钉了，没有讨论余地了。 本来就是试错改错的过程，没必要一条路走到底
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
哥们呀，哥们
- 对于发行版： Arch系，debian系，Fedora，Geentoo, FreeBSD, Slackware 等都没惯着, 都用的loong64.
- 对于软件包，除了和gcc绑死的一些软件，绝大多数的软件都是loong64
求同存异，AOSC用loongarch64，这是极少数的例子。不至于打破现有的共识啊！
将心比心，AOSC用户喜欢用loongarch64, 那我Arch用户也同样喜欢loong64喜欢的不得了。 意见不同是正常的啊，但要发展，要求同存异啊哥们。 已经有既定的事实了，主流社区已经焊死在loong64了，至于再搅一次吗
目前命名方式造成的主要问题是编译clash-verge-rev的时候抓不到包，无论是abi1/2的命名方式还是loong64/looangarch64的方式，并无法解决这一核心问题，仍然需要编译的时候patch
verge还没有正式支持loong64，check脚本里写的只是之前遗留的，在正式支持loong64的时候verge会按照mihomo的命名进行修改，所以verge那边怎么写不应该是mihomo这边是否应该修改的论据，如果要请求mihomo修改命名应该从其他方面举证。
const ARCH_MAP = {
"x86_64-pc-windows-msvc": "x64",
"i686-pc-windows-msvc": "ia32",
"aarch64-pc-windows-msvc": "arm64",
"x86_64-apple-darwin": "x64",
"aarch64-apple-darwin": "arm64",
"x86_64-unknown-linux-gnu": "x64",
"i686-unknown-linux-gnu": "ia32",
"aarch64-unknown-linux-gnu": "arm64",
"armv7-unknown-linux-gnueabihf": "arm",
"riscv64gc-unknown-linux-gnu": "riscv64",
"loongarch64-unknown-linux-gnu": "loong64",
};
在此处clash-verge-rev的代码中，无论新旧世界都会映射为loong64，这是问题的根源
目前命名方式造成的主要问题是编译clash-verge-rev的时候抓不到包，无论是abi1/2的命名方式还是loong64/looangarch64的方式，并无法解决这一核心问题，仍然需要编译的时候patch
现在clash-verge-rev默认抓包是loong64规则的包，这个之前已经merge了。clash-verge-rev是没有问题的。
建议去clash-verge-rev那边讨论如何在check脚本中区分新旧世界
我个人认为，目前clash-verge-rev对于新世界loong64的做法是没有问题的。 至于如果要增加旧世界支持，建议千万不要像mihomo一样，改掉新世界loong64了