Revert "{citra,yuzuPackages}: remove package" #295587
Conversation
|
I would want to wait for the dust to settle a little bit, so we can be more confident this isn't going to lead to a DMCA strike or whatever. |
|
That is my intention. Revert to the status quo, wait for an actual issue to crop up (i.e. DMCA notice) and then take a more extreme action. I highly doubt Ninty would dare to attempt their corporate shitfuckery to this extent outside the US though. |
|
I concur with @K900 here. Let's wait, there is no reason to restore those packages until we have a proper upstream (that is also not DMCA'd). For everyone that wants to use those packages, you can always just copy the derivation to your configuration and get a copy of the repo somewhere. Edit: sorry, pinged the wrong person in the original reply. |
That's the point I disagree with. These packages have users and they work for them. We are actively removing functionality from their systems. This was not a cleanup of dead or broken code; it still works. I just built yuzu right on my system. The source came from cache.nixos.org which is obviously not ideal but not the end of the world either. I intended to keep this rather simple to unbreak users but switching out the sources for an alive mirror should be rather simple and would leave the yuzu package without any significant technical issue. |
ofborg
bot
requested review from
abbradar,
IvarWithoutBones,
kira64xyz and
sbruder
Removal of packages or features will always break someone relying on that functionality. Heck, even a refactor made wrong will break some users. In the end we need to decide between what is worth maintaining and what it is not, and in my opinion keeping those packages is not worth maintaining them until we get a new upstream that will not be DMCA'd next week.
I think we agree to disagree at this point. |
|
It should also be emphasized that the early-access source code provided by pineappleEA is still available and has been available despite upstream yuzu being taken down. |
It doesn't help that I would be ok if However I would still prefer to wait because I am sure eventually an actual upstream will appear. |
I fail to see any sort of maintenance burden here. I can assure you that the package will not have to account for upstream changes in the foreseeable future ;) I'm willing to step up as a maintainer in the interim if you're at all worried. I'm also again of the opinion that packages should not be removed on the grounds that there could potentially possibly be a burden sometime far into the future but rather at the point where an actual burden materialises.
That's enough for them to function as a mirror which is all we need to mend the "pressing" technical issue of source unavailability. Yes, upstream development is no longer taking place. If I had to guess the same is true for 1000s if not 10000s of packages in Nixpkgs; they're not hurting anyone. |
Maintenance burden also happens when we do any changes in dependencies that can break because a package depends in an older version of this package. Generally who handles those fixes is upstream, but without an upstream who is going to do those? In lack of upstream doing the change (because e.g.: they don't support third-party packaging for example) we can do it ourselves, but generally having the source code available is crucial for those cases and right now we don't (unless you download the code from Hydra, that really is a PITA).
See point above. |
Yes, because upstream died.
This is literally a dead and broken code, since the upstream repo disappeared.
Let the NURers do it, then.
Including security bugs (that will be discovered some day) that we will not patch (since we are mere packagers)? This is precisely another argument for removal, not for keeping the corpse. |
Remembering that Hydra merely downloads raw code, not its Git history. |
There was a problem hiding this comment.
I am in favor of keeping around.
There is nothing that would make this criminal anyways, just like youtube-dl isn't criminal.
Indeed SuYu looks quite active already, and even if that project dies there is going to be ten new ones. I don't worry about maintenance burden falling on nixpkgs devs at all. Quite the opposite, this is one of the easier packages compared to the other corpses we have lying around (OpenCV2 anyone?).
This is not about legal conundrums, but about the removal of a dead software.
Are you arguing for packaging Suyu or for reverting the removal of Yuzu? |
|
I would suggest reverting the removal of Yuzu now, and switching the source over to SuYu (or whatever fork seems to align most with former yuzu) at a later point (when a suitable tagged version is available). |
|
Inaccessible tarballs that only work by the grace of If we were changing the package to point to a new fork or something, it'd be a different story. |
Ah, I had assumed the first part of the sentence was the main point. I'll respond to the latter:
Mirrors exist for it everywhere. Good access to code is obviously desirable (certainly in the long term) but it's not like it's been banished off the face of the earth. If you really need it, it's easy to get. I'd also assume the active maintainers have a local copy anyways. It won't prevent anyone from creating patches.
I have sympathy for this but in this specific case, if yuzu were to actually break because of a dependency, then that would be the time to remove it. (Not without giving its maintainers a chance to resolve the issues themselves of course.) It has known problems, nobody could expect outside maintainers to care much about the wellbeing of a package with known issues. We currently don't have the infrastructure for a standardised method of declaring it as such yet but we can still do so in other ways. What would you think of a comment at the top of the file stating that the package does not have an alive upstream but is kept because it has active users and is subject to removal once it falls into disrepair? Effectively a sort of deprecation notice.
It's a subtle distinction but being rolling release does not mean deps become incompatible ways "all the time" but that deps could become incompatible at any time rather than at specific times. It still has to happen in the first place. It could happen at any time but that doesn't mean it's likely to happen short-term. Long-term, I'd agree; I could certainly see Yuzu breaking due to a dep upgrade in a year or two.
Of course no upstream patches would be the underlying cause but the maintenance burden for dep maintainers would only materialise if yuzu was a significant breakage and they were somehow obliged to care about it.
As mentioned, this is not the case. The git history didn't magically disappear off the internet.
I was specifically talking about arguments against the source being MIA somehow being a critical issue. Sorry for not making that clear enough. |
|
I had intended for this to become a simple reversion to the status quo and was not expecting to be expected to bring improvements over the status quo but I don't mind doing these. So for progress on this PR:
|
This solves the technical issue of upstream sources being unavailable. Which doesn't block the build because the source is cached on cache.nixos.org but breaks an aspect of reproducibility because others can no longer reproduce the source without the binary cache. As you can see, the hashes are all the same; no content has changed. The implementation is quite complex because fetchgit isn't made to use mirrors for submodules and submodules are also just kind of a pain to deal with in general. (The code could be deduplicated but it's expected to be obsolete in a few month's time.) yuzu-ea did not have to be touched; its source is still available.
|
I did the thing and all sources are now reproducible again. It's not pretty but it works and is good enough. I also added the notice and made myself the maintainer of these packages for the interim. I'll again extend my offer to the previous maintainers to remove them if they no longer wish to maintain these packages. |
Again, those are arguments for issues that will happen. The question is not what or if, it is when here.
I am tired of this discussion and the sarcastic (and passive-aggressive) tone (from both sides actually, this is not just direct to OP). I will unfollow this thread. My point still stands, and I am not really happy to the proposed solution (pointing to random repository mirrors, especially because the changes keep the update scripts). I am ok for opening a new PR packaging Suyu or some other fork, but please don't ping me to be a reviewer since I don't want to be part of this discussion anymore. |
Let me be clear here: I'm not happy about this at all either but it is an interim solution and for that, it's good enough.
Good point, forgot about those. They're actually dead code this time. |
Won't be getting updates any time soon :(
|
I'm unsubscribing from this discussion as well. I believe this entire proposal is driven by some kind of emotional desire not to give up on Yuzu, which I empathize with. My stance is that this change should not be reverted, |
Since Staging brings too many mass-rebuild packages to Master, it has bigger probability of clash. Any "mirror" of the most recent Yuzu code falls under the first condition for "not being accepted" under the packaging guidelines
Bold mine.
This is precisely the tone you are directing this pull request: keeping a dead-upstream package at all costs.
I gave two examples of similar polemics of keeping a software after its EOL.
We can anything we like (given that it is not a sin or a crime or a trigger for a Nintendo lawsuit).
Even after reasonable notice and attempted alternatives, Profpatsch loudly complained about their packages being removed. Looks like the story is repeating.
We have at least two problems here.
This expression is being kept with the help of too much devices.
As I said before, maintaining a collection of patches for a backup of a dead upstream is not our duty.
Not going into the intricacies of Python projects,
This "exclusive we" is an argument for keeping this in a NUR, not in the Nixpkgs monorepo.
And this is the master point of the original pull request you are now reverting.
Point taken.
This is the tone of your whole banzé. Your arguments always impose a series of "maybe" steps before removal of this dead upstream.
You are being sarcastic and passive-aggressive all the time. "Pot meets kettle", as they say in Anglophone world? LOL Answering the hidden contentIt's funny when you rely on passive-agressive behavior, whereas when I retort in the same tone pointing out the ridiculousness of your "keep it indefinitely" proposal, your reaction is a threat to call the mods! Maybe I should need to learn how to be more sensitive to sarcasm and threaten to call the mods when I am the target of one!
Again, another argument for keeping it in a NUR.
Just to be sure, Yuzu depends on Qt and CMake. It will be impossible to ignore it when/if they become incompatible - yet another reason to NURing it. Further, personalizing arguments this way is a little bit dishonest. Not that you care, seemingly...
Paraphrasing myself: Your purpose, from what you wrote - from what you wrote -, is not merely reverting a premature PR, but keeping this packages indefinitely. I can't read your mind, I can only read your words. |
|
suyu release is out, let's move to it |
|
I would give it some more time. The 0.0.2 release of suyu is ... extremely messy. |
|
hi team 👋 where are we on this? new release coming up, it would be nice to have something easily available... |
|
Yuzu is very dead. |
|
i think everyone here understands that - so what will we do? package |
|
Recommend people to use Ryujinx. Suyu is effectively also dead. |
What about for 3ds emulation? |
|
We can see which of the forks is alive, if any, and package that. |
|
Lime3ds, I believe... |
Panda3DS too (not a fork but an independent 3ds emulator) |
Description of changes
As explained in #293312 (comment), an upstream source no longer being available does not warrant an immediate removal of a package that can build fine with cached sources for the time being.
Approval was only given by one of the 5 maintainers; the rest were not even notified. (This PR should ping them again.)
This is especially not an appropriate reaction when it is a package many people (including myself) used up until that point. Even if removal was the appropriate action, there should have been a grace period.
Appropriate measures for this issue I can think of:
Until such an appropriate measure is taken, revert to the previous status quo: A fully working Yuzu derivation with a minor problem for an extremely limited amount of users.
(If the maintainers do not wish to be listed here anymore because the package is "problematic" now, please speak out.)
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.