-
Notifications
You must be signed in to change notification settings - Fork 261
luajit: update to 2.1.1724512491 #1632
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.
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
Closed
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2219,6 +2219,7 @@ | |
| "luajit" | ||
| ], | ||
| "versions": [ | ||
| "2.1.1724512491-1", | ||
| "2.1.1720049189-1", | ||
| "2.1.1713773202-1" | ||
| ] | ||
|
|
||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is unfortunate, but these releases should not have been put here in the first place. WrapDB has a policy that we only add pristine upstream releases, not random Git snapshots.
The 2.1 release can be added only after they have made a proper release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cf. #1325 (comment).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You really have to get your act together (members of the project). Same with respect to merging PR with failing jobs, where you and others don't seem to have the same policy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@benoit-pierre @jpakkane Does this mean that luajit will never be updated in wrapdb? I'd suggest to remove it in this case, as there are important fixes missing, including security ones.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does upstream never intend to do another release?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From the download page:
From this it seems pretty clear that they don't really want LuaJIT packaged. I'm inclined to oblige them. #2529 proposes to add a deprecation mechanism and mark luajit deprecated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the usecase. Additionally, no one one said that wrap can't track master branch like the author wants you to do, if you want to oblige them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WrapDB is not a package manager for anyone's operating system and does not provide pre-built packages, so a literal reading excludes us. (The distinction upstream is trying to draw between "third parties" and "distro maintainers" is pretty tenuous though.) Even if not, the wording is... reluctant, and upstream tries to exert control over downstream choices that are not properly within their purview. By policy we don't do backports here, but it's still a red flag.
WrapDB policy requires upstream releases, so LuaJIT should not have been packaged here in the first place. In any case, we're not equipped to "frequently" update to upstream HEAD just in case something important changed. The purpose of a release is to signal that something important changed and downstreams should update.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll play devil's advocate here. I understand maintainer to not want the noise of releases if their project doesn't fit this model. The expectation of releases is also long term support, at least of the latest release. With important fixes backported. The point in luajit is that it's not a huge project or framework consisting of multiple modules or something like that. In practice any and all change is important. And backporting this to some "releases" is just a noise. I know it doesn't fit mental model of most people thinking about OSS, but I understand that. On top of that, you have distributions that uses ancient packages/releases. Why it should be project maintainer responsibility to keep those "releases" up to date? And don't give me that package maintainers will do that, because they never do, unless there is critical CVE reported.
In luajit case, effectively every commit is new release. And should be backported to any and all distributions. I don't think upstream tries to exert control over downstream choices, upstream just says that only top of the tree version is the supported one. How would that be any different if they automatized release process, and do weekly point releases?
I love getting those bug reports from debian users about bugs fixed 4 years ago...
That's fair. Frankly the solution would be to have a wrap file that just downloads master branch. However if that's not acceptable and merging frequent update PR is also not acceptable, there is only third choice to remove it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, most open-source projects don't work this way. When the code is ready for a wider audience, upstream picks a version number indicating whether there are new features or breaking changes (using semver or similar), ships a source tarball, and moves on. It's nice if they write a changelog, but lots of projects don't do that either. That's the end of their responsibility for that release.
That isn't actually true. Removing a deprecated feature breaks ABI compatibility with old binaries. Adding an API breaks ABI compatibility of new binaries (if they use the API) with old libraries. Fixing a security bug mitigates consequences outside the design scope of the library. A spelling fix hopefully breaks nothing.
It absolutely is not upstream's responsibility. If downstream wants to do backports, they can. If downstream wants to do backports badly, they can. If the package breaks, downstream gets to keep both pieces. Upstream isn't responsible for downstream.
In many cases where upstreams do frequent releases, downstreams don't package every one of them; and it's clear from the version number exactly how out-of-date the downstream package is. And those upstreams don't try to tell downstream that that's wrong somehow.
Look, upstream is free to support or not support whatever they want. Not providing sequential version numbers is somewhat user-hostile, since it's impossible to compare two commit hashes by inspection. But an upstream lecturing downstreams about what they should do (and whether they should even exist) suggests that upstream could be hostile in other ways that might matter much more for downstream maintenance.
We don't allow wraps to point to the main branch because our users expect the code to stay the same until they update the wrap. Also, for ports, we may need to manually change the Meson config to reflect upstream changes.
Even if we did allow commit hashes, we're a volunteer project. We can't force anyone to submit or review the frequent updates upstream wants us to make.