clash: reinit at 1.18.0

[aaronjheng]

Description of changes

See #266747.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[winterqt]

I am not a fan of this package being reintroduced under the same name with a random (your) repository as the source.

Even though at a glance it looks like you didn't change anything, I think it may be a bit disingenuous to users to do this.

I'm going to ask for opinions on this in #dev on Matrix, but in the meantime, blocking this merge.

[aaronjheng]

I am not a fan of this package being reintroduced under the same name with a random (your) repository as the source.

Me neither. However, I don't have a better idea right now.

I'm going to ask for opinions on this in #dev on Matrix, but in the meantime, blocking this merge.

Thanks.

[mweinelt]

I'm somewhat surprised you sent this without giving any kind of reasoning and no reference to why this is apparently necessary.

[SuperSandro2000]

based on the matrix discussion we decided against adding the repo back https://matrix.to/#/!kjdutkOsheZdjqYmqp:nixos.org/$ZazXgab641hf6QtQnvfilcWxZXlOzLJZCGSiKn0BM2E?via=lossy.network&via=matrix.org&via=nixos.dev

[emilazy]

I wouldn't describe that as the consensus at all. We would want a reasonably verifiable archive of the last version (preferably with the same hash, e.g. a Wayback Machine archive of a GitHub tarball), or a new forked upstream that we can reasonably point to as being widely-accepted.

[winterqt]

Yeah, no, we did not have a consensus at all. Re-opening.

[winterqt]

Could grab from SWH: https://archive.softwareheritage.org/browse/origin/directory/?origin_url=https://github.com/Dreamacro/clash

[Aleksanaa]

While we can grab it from software heritage, or another fork, I don't think it will be in a good maintenance status (or even receive any maintenance). Upstream has made it clear that it will no longer continue to develop this software about 9 months ago. If any collaborators would continue to develop, a maintained fork should appear quite soon after that. Nixpkgs is not a graveyard for outdated projects, and we are working hard to phase out those parts.

Of course, if your fork reflects good maintenance and receives a certain amount of attention (Note that there is no standard as of now, but at least they shouldn't be completely absent), we can also consider adding it back. Until then, you can use methods like flakes and NUR to make your package available to people.

On the other hand, other graphical clash clients are using clash-meta as the backend in Nixpkgs. Is there any functional shortcoming between clash-meta and the original clash?

[aaronjheng]

If a package:

1. Has not had any upstream maintenance for over 9 months

2. Does not have any notable forks with significant attention

Can we delete this package?

[Aleksanaa]

1. Has not had any upstream maintenance for over 9 months

It's not just having no maintenance, it's the upstream clearly abandoned the project, using a more decisive method than archive.

And:

3. Certain alternatives exist

4. It's not a dependency of any other packages, aka a leaf package, and not a dependency of any new package (that's not in this situation) someone wants to add

[aaronjheng]

It's not just having no maintenance, it's the upstream clearly abandoned the project, using a more decisive method than archive.

Fair enough. But how long should we wait? Immediately? A few months or years?

[phanirithvij]

NixOS/rfcs#180 is the proposal @aaronjheng

[aaronjheng]

After reading this RFC, I believe it is not closely related to this PR. Before it was removed last time, clash was neither broken nor unmaintained (if I understand correctly, the “unmaintained” in the RFC refers to the package in nixpkgs, not the upstream project).