Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Feature] 关于龙架构二进制文件名的建议 #1141

Open
2 tasks done
LinuxResearcher opened this issue Mar 28, 2024 · 57 comments
Open
2 tasks done

[Feature] 关于龙架构二进制文件名的建议 #1141

LinuxResearcher opened this issue Mar 28, 2024 · 57 comments
Labels
enhancement New feature or request

Comments

@LinuxResearcher
Copy link

Verify steps

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 LinuxResearcher added the enhancement New feature or request label Mar 28, 2024
@xishang0128
Copy link

@LinuxResearcher loongarch64和loong64的区分不够清晰,不如abi1/2

@LinuxResearcher
Copy link
Author

@LinuxResearcher loongarch64和loong64的区分不够清晰,不如abi1/2

的确，abi1/2非常清晰。主要是龙架构旧世界的软件包架构名都是loongarch64，新架构都是loong64。关于这一点，龙芯用户是能区分的，其他用户无需关注。其他架构都不带abi1/2，龙架构的带着很不顺眼啊。

@ToKingl
Copy link

ToKingl commented Apr 6, 2024 •
edited

@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😏

@ToKingl
Copy link

ToKingl commented Apr 6, 2024

@LinuxResearcher loongarch64和loong64的区分不够清晰,不如abi1/2

大大，可以考虑一下按照龙芯官方的loongarch64-abi1和loongarch64-abi2命名法进行命名吗？

@LinuxResearcher
Copy link
Author

@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的约定，其他发行版都遵守这个约定了。

@ToKingl
Copy link

ToKingl commented Apr 7, 2024

@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 命名

@ToKingl
Copy link

ToKingl commented Apr 7, 2024 •
edited

@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
Copy link
Author

LinuxResearcher commented Apr 7, 2024 •
edited

@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是龙芯中科的商标，其实这种命名很傻屄。

@ToKingl
Copy link

ToKingl commented Apr 7, 2024

@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
Copy link
Author

@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。

@TurnOffNOD
Copy link

TurnOffNOD commented Apr 7, 2024 •
edited

这个命名规则，龙芯那边有官方文档来约束没？

@LinuxResearcher
Copy link
Author

LinuxResearcher commented Apr 7, 2024 •
edited

这个命名规则，龙芯那边有官方文档来约束没？

目前没有，现在只有默认的做法，并且已经开始混乱了。

不过，可以确定的是，所有旧世界架构名都是loongarch64。而新世界这方面，debian是发行版的重要标准参考，debian是把架构名定为loong64的，已经进dpkg上游了。更早的gentoo也是loong64，龙芯官方的新世界发行版LoongArchLinux也是loong64。
https://wiki.debian.org/Ports/loong64
https://wiki.debian.org/LoongArch

@ToKingl
Copy link

ToKingl commented Apr 7, 2024

这个命名规则，龙芯那边有官方文档来约束没？

目前没有，现在只有默认的做法，并且已经开始混乱了。

不过，可以确定的是，所有旧世界架构名都是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/
image

@LinuxResearcher
Copy link
Author

这个命名规则，龙芯那边有官方文档来约束没？

目前没有，现在只有默认的做法，并且已经开始混乱了。
不过，可以确定的是，所有旧世界架构名都是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/ image

这个目录是刘工移植的龙芯2F安装方式，刘工自己打包的debian系统。这个loongarch64是刘工起的文件名，架构名还是loong64。不信你安装上去看看，里面的软件包是不是带loong64后缀。还有，这里的软件包全部来自http://ftp.ports.debian.org/debian-ports/pool-loong64/main/

@TurnOffNOD
Copy link

这个命名规则，龙芯那边有官方文档来约束没？

目前没有，现在只有默认的做法，并且已经开始混乱了。

不过，可以确定的是，所有旧世界架构名都是loongarch64。而新世界这方面，debian是发行版的重要标准参考，debian是把架构名定为loong64的，已经进dpkg上游了。更早的gentoo也是loong64，龙芯官方的新世界发行版LoongArchLinux也是loong64。 https://wiki.debian.org/Ports/loong64 https://wiki.debian.org/LoongArch

官方不说话，那就一定会混乱了。

@LinuxResearcher
Copy link
Author

这个命名规则，龙芯那边有官方文档来约束没？

目前没有，现在只有默认的做法，并且已经开始混乱了。
不过，可以确定的是，所有旧世界架构名都是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的架构名作为包架构名，并且喜欢和商标一致。

@Kiri2002
Copy link

强烈请求支持新世界的的命名：
mihomo-linux-loong64-alpha-0b4662e.gz
如果需要保留abi的写法，可以单独添加一个上面名称的包。

  1. loong64是主流的新世界叫法，毋庸置疑了。没有讨论的余地了。
  2. 旧世界将缓慢淘汰。
  3. mihomo作为上游包，被下游依赖。小改动可能会影响很大，希望慎重，不要留下历史包袱和遗憾。
  4. 许多下游包遵循了默认的命名格式，抓mihomo。如（clash-verge） abi格式的抓不到，干脆先单独加个经典格式的loong64包，稳定下游，再慢慢讨论。

@ToKingl
Copy link

ToKingl commented Apr 25, 2024 via email

@Kiri2002
Copy link

目前龙芯官方还未在新世界中提供显卡驱动，所以旧世界也还会在未来存在一段时间。 况且新旧世界的区分从来就不是用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: @.***>

现在不是说，龙芯定啥标准，社区就怎么去干。

  1. 现在的既定事实是社区广泛支持loong64命名。
  2. 开源/自由软件社区主要就是为新世界打包的，是去适配新世界的。
  3. 用loong64的命名方案已经是主流的支持了，简洁优雅

如果非要辩论很久，完全可以考虑单独提供mihomo-linux-loong64-alpha-0b4662e.gz命名的包，和其他的并存。

明明是很容易能做到 简洁，优雅，一致的事情， 真不至于

@Kiri2002
Copy link

补充一下，绝大多数的开源社区维护新世界包，没有采用abi1/abi2的命名规则，真没必要再弄一套小众规则了

@ToKingl
Copy link

ToKingl commented Apr 25, 2024 via email

@Kiri2002
Copy link

对于社区，龙芯的标准好，就采用，不好，就不采用。

对于龙芯： “只要你说的对，我们就改正，只要你说的对人民有好处，我们就照你说的办”

loong64已经是板上钉钉了，没有讨论余地了。
本来就是试错改错的过程，没必要一条路走到底

@ToKingl
Copy link

ToKingl commented Apr 25, 2024 via email

@Kiri2002
Copy link

哥们呀，哥们

  1. 对于发行版： Arch系，debian系，Fedora，Geentoo, FreeBSD, Slackware 等都没惯着, 都用的loong64.
  2. 对于软件包，除了和gcc绑死的一些软件，绝大多数的软件都是loong64

求同存异，AOSC用loongarch64，这是极少数的例子。不至于打破现有的共识啊！

@Kiri2002
Copy link

Kiri2002 commented Apr 25, 2024 •
edited

将心比心，AOSC用户喜欢用loongarch64, 那我Arch用户也同样喜欢loong64喜欢的不得了。
意见不同是正常的啊，但要发展，要求同存异啊哥们。
已经有既定的事实了，主流社区已经焊死在loong64了，至于再搅一次吗

@ziqi-cn
Copy link

ziqi-cn commented Apr 25, 2024

目前命名方式造成的主要问题是编译clash-verge-rev的时候抓不到包，无论是abi1/2的命名方式还是loong64/looangarch64的方式，并无法解决这一核心问题，仍然需要编译的时候patch

@MystiPanda
Copy link

verge还没有正式支持loong64，check脚本里写的只是之前遗留的，在正式支持loong64的时候verge会按照mihomo的命名进行修改，所以verge那边怎么写不应该是mihomo这边是否应该修改的论据，如果要请求mihomo修改命名应该从其他方面举证。

@ziqi-cn
Copy link

ziqi-cn commented Apr 25, 2024 

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，这是问题的根源

@ziqi-cn
Copy link

ziqi-cn commented Apr 25, 2024

建议去clash-verge-rev那边讨论如何在check脚本中区分新旧世界

@Kiri2002
Copy link

Kiri2002 commented Apr 25, 2024 •
edited

目前命名方式造成的主要问题是编译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了

@MystiPanda
Copy link

verge 不打算支持旧世界，verge 怎么写并不是问题的根源，因为 verge 还没正式支持 loong64，在正式支持的时候这里会对应 mihomo 中新世界的命名。

@ziqi-cn
Copy link

ziqi-cn commented Apr 25, 2024

verge 不打算支持旧世界，verge 怎么写并不是问题的根源，因为 verge 还没正式支持 loong64，在正式支持的时候这里会对应 mihomo 中新世界的命名。

既然如此，为何不将check脚本中的链接改为当前新世界版本的链接，至少在新世界编译时不需要patch了。

由于此处的包名不会造成实质性问题，建议先等待观察龙芯官方和新世界商业发行版动态，作为上游，首要的是保持稳定，在没有充分理由的情况下不应频繁更改命名规则。

@Kiri2002
Copy link

Kiri2002 commented Apr 25, 2024 •
edited

是从这个commit起，加的loong64-abi-1/2.

其中构建过程抓go包，抓的不是go官方的包，而是提交者@xishang0128自己github fork的go包，这真的好吗？

    - name: Set up Go1.21 loongarch abi1
      if: ${{ matrix.jobs.goarch == 'loong64' && matrix.jobs.abi == '1' }}
      run: |
        wget -q https://github.com/xishang0128/loongarch64-golang/releases/download/1.21.5/go1.21.5.linux-amd64-abi1.tar.gz

旧世界这么抓，是因为go没提供旧世界的包，没有办法。新世界为什么不用go官方的包？从第三方私人的仓库抓，我认为这不是个好的做法，也不安全

@Kiri2002
Copy link

verge 不打算支持旧世界，verge 怎么写并不是问题的根源，因为 verge 还没正式支持 loong64，在正式支持的时候这里会对应 mihomo 中新世界的命名。

既然如此，为何不将check脚本中的链接改为当前新世界版本的链接，至少在新世界编译时不需要patch了。

由于此处的包名不会造成实质性问题，建议先等待观察龙芯官方和新世界商业发行版动态，作为上游，首要的是保持稳定，在没有充分理由的情况下不应频繁更改命名规则。

正如您说的，“作为上游，首要的是保持稳定，在没有充分理由的情况下不应频繁更改命名规则。”，从这个commit前，mihomo一直是loong64的规范命名规则，当时也能打出来老版本的clash-verge。后面为什么突然改了？

建议mihomo先解决争议，稳定命名后，下游再更。总不能上游反复改，下游跟着遭殃

@xishang0128
Copy link

xishang0128 commented Apr 25, 2024 •
edited

是从这个commit起，加的loong64-abi-1/2.

其中构建过程抓go包，抓的不是go官方的包，而是提交者@xishang0128自己github fork的go包，这真的好吗？

    - name: Set up Go1.21 loongarch abi1
      if: ${{ matrix.jobs.goarch == 'loong64' && matrix.jobs.abi == '1' }}
      run: |
        wget -q https://github.com/xishang0128/loongarch64-golang/releases/download/1.21.5/go1.21.5.linux-amd64-abi1.tar.gz

龙芯自己的下载源太慢，所以存github有问题吗，更何况这是龙芯自己的命名，他自己区分的abi版本

image

@Kiri2002
Copy link

Kiri2002 commented Apr 25, 2024 •
edited

是从这个commit起，加的loong64-abi-1/2.
其中构建过程抓go包，抓的不是go官方的包，而是提交者@xishang0128自己github fork的go包，这真的好吗？

    - name: Set up Go1.21 loongarch abi1
      if: ${{ matrix.jobs.goarch == 'loong64' && matrix.jobs.abi == '1' }}
      run: |
        wget -q https://github.com/xishang0128/loongarch64-golang/releases/download/1.21.5/go1.21.5.linux-amd64-abi1.tar.gz

龙芯自己的下载源太慢，所以存github有问题吗，更何况这是龙芯自己的命名，他自己区分的abi版本

image

新世界用go官方的loong64包就行：https://go.dev/dl/go1.22.2.linux-loong64.tar.gz
image

这个commit本来只是增加旧世界的支持，为什么要改新世界的包源？
有官方包支持的情况下不用三方包，（在这里包括龙芯公司的包）这是开源社区主流的共识。一方面统一版本，另一方面，安全问题，杜绝加料的风险。官方源有眼睛盯着，三方源没有那么多人关注！

另外，三方源有滞后性。这对滚动发行的发行版是致命的危险（如Archlinux）

@ziqi-cn
Copy link

ziqi-cn commented Apr 25, 2024

verge 不打算支持旧世界，verge 怎么写并不是问题的根源，因为 verge 还没正式支持 loong64，在正式支持的时候这里会对应 mihomo 中新世界的命名。

既然如此，为何不将check脚本中的链接改为当前新世界版本的链接，至少在新世界编译时不需要patch了。
由于此处的包名不会造成实质性问题，建议先等待观察龙芯官方和新世界商业发行版动态，作为上游，首要的是保持稳定，在没有充分理由的情况下不应频繁更改命名规则。

正如您说的，“作为上游，首要的是保持稳定，在没有充分理由的情况下不应频繁更改命名规则。”，从这个commit前，mihomo一直是loong64的规范命名规则，当时也能打出来老版本的clash-verge。后面为什么突然改了？

建议mihomo先解决争议，稳定命名后，下游再更。总不能上游反复改，下游跟着遭殃

mihomo增加abi1/2是因为此issue #1062

在此之前mihomo只有新世界包，此后增加了旧世界包，因此出现了区分新旧世界的需求

@Kiri2002
Copy link

Kiri2002 commented Apr 25, 2024 •
edited

verge 不打算支持旧世界，verge 怎么写并不是问题的根源，因为 verge 还没正式支持 loong64，在正式支持的时候这里会对应 mihomo 中新世界的命名。

既然如此，为何不将check脚本中的链接改为当前新世界版本的链接，至少在新世界编译时不需要patch了。
由于此处的包名不会造成实质性问题，建议先等待观察龙芯官方和新世界商业发行版动态，作为上游，首要的是保持稳定，在没有充分理由的情况下不应频繁更改命名规则。

正如您说的，“作为上游，首要的是保持稳定，在没有充分理由的情况下不应频繁更改命名规则。”，从这个commit前，mihomo一直是loong64的规范命名规则，当时也能打出来老版本的clash-verge。后面为什么突然改了？
建议mihomo先解决争议，稳定命名后，下游再更。总不能上游反复改，下游跟着遭殃

mihomo增加abi1/2是因为此issue #1062

在此之前mihomo只有新世界包，此后增加了旧世界包，因此出现了区分新旧世界的需求

同样的“在没有充分理由的情况下不应频繁更改命名规则”，完全可以用loongarch64或别的进行区分。完全可以不动新世界的loong64命名。这么一改，新世界的也用不了了。
不觉得这么做很过分吗？

@ziqi-cn
Copy link

ziqi-cn commented Apr 25, 2024 

        if [ "${{matrix.jobs.goarch}}" = "loong64" ]; then
          ARCH=loongarch64
        else
          ARCH=${{matrix.jobs.goarch}}
        fi

我观察到这里不区分新旧世界架构名一律为loongarch64，是否有待商榷

@Kiri2002
Copy link

Kiri2002 commented Apr 25, 2024 •
edited

我认为，采取新世界loong64，旧世界loongarch64这种最主流的办法是目前最好的办法
既支持了旧世界，又不影响新世界，还符合了主流惯例，并且优雅简洁美丽
PR在这#1218
大佬@xishang0128，您觉得呢？

@Kiri2002 Kiri2002 mentioned this issue Apr 25, 2024
Closed
@ToKingl
Copy link

ToKingl commented Apr 25, 2024

我认为，采取新世界loong64，旧世界loongarch64这种最主流的办法是目前最好的办法 既支持了旧世界，又不影响新世界，还符合了主流惯例，并且优雅简洁美丽 PR在这#1218 大佬@xishang0128，您觉得呢？

不是已经说了，因为 verge 还没正式支持 loong64，在正式支持的时候这里会对应 mihomo 中新世界的命名。作为上游，首要的是保持稳定，在没有充分理由的情况下不应频繁更改命名规则。

@LinuxResearcher
Copy link
Author

LinuxResearcher commented Apr 25, 2024 via email

@LinuxResearcher
Copy link
Author

LinuxResearcher commented Apr 25, 2024 via email

@ToKingl
Copy link

ToKingl commented Apr 25, 2024 via email

@ziqi-cn
Copy link

ziqi-cn commented Apr 25, 2024

那么能建议mihomo也放弃对旧世界的支持吗？开源软件发行旧世界二进制的，好像mihomo是独一个。
…
---原始邮件--- 发件人: @.> 发送时间: 2024年4月26日(周五) 凌晨0:47 收件人: @.>; 抄送: @.@.>; 主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141) verge 不打算支持旧世界，verge 怎么写并不是问题的根源，因为 verge 还没正式支持 loong64，在正式支持的时候这里会对应 mihomo 中新世界的命名。 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

这样不好，新世界发行版很多都有mihomo的包（AOSC，LoongArchLinux，Deepin），反而是旧世界没有，也不可能有包，这里发布的旧世界包反而更有价值。

@LinuxResearcher
Copy link
Author

LinuxResearcher commented Apr 25, 2024 via email

@LinuxResearcher
Copy link
Author

LinuxResearcher commented Apr 25, 2024 via email

@ToKingl
Copy link

ToKingl commented Apr 25, 2024 via email

@LinuxResearcher
Copy link
Author

LinuxResearcher commented Apr 25, 2024 via email

@ToKingl
Copy link

ToKingl commented Apr 25, 2024 via email

@LinuxResearcher
Copy link
Author

LinuxResearcher commented Apr 26, 2024 via email

@ToKingl
Copy link

ToKingl commented Apr 26, 2024 via email

@LinuxResearcher
Copy link
Author

LinuxResearcher commented Apr 26, 2024 via email

@LinuxResearcher
Copy link
Author

LinuxResearcher commented Apr 26, 2024 via email

@ToKingl
Copy link

ToKingl commented Apr 26, 2024 via email

@ToKingl
Copy link

ToKingl commented Apr 26, 2024 •
edited

非要那么极端吗？非要在二者中选一个吗？
有时候真替龙芯感到悲哀，自己对自己家产品的命名权还得不到应有的尊重，非要外来者进行横插一杠、指手画脚。这就相当于明明你有正式的名字，但别人非给你再取个绰号，还美其名曰名字太长了，不够显眼，然后就这么一直这么地叫你

@Kiri2002
Copy link

旧世界爱叫啥叫啥，不会有历史包袱。
新世界统一loong64，尊重社区主流。
社区绝大多数是用爱发电，可不拿工资

@MetaCubeX MetaCubeX locked as too heated and limited conversation to collaborators Apr 26, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@TurnOffNOD @LinuxResearcher @ziqi-cn @xishang0128 @Kiri2002 @ToKingl @MystiPanda