luajit: update to 2.1.1724512491 #1632
Conversation
| directory = LuaJIT-f725e44cda8f359869bf8f92ce71787ddca45618 | ||
| source_url = https://github.com/LuaJIT/LuaJIT/archive/f725e44cda8f359869bf8f92ce71787ddca45618.tar.gz | ||
| source_filename = luajit-2.1.1724512491.tar.gz | ||
| source_hash = 2b5514bd6a6573cb6111b43d013e952cbaf46762d14ebe26c872ddb80b5a84e0 |
There was a problem hiding this comment.
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.
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.
@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.
Does upstream never intend to do another release?
There was a problem hiding this comment.
From the download page:
Do not use pseudo-releases or tarballs created by third parties. Do not use binaries offered for download by third parties.
Pre-built packages should only be installed via a trusted package manager for your operating system (distro). But you should be aware these often carry old versions that miss important fixes. Before reporting an issue, always try the latest version available from the git repository.
Distro maintainers for distros that require the fiction of a release should do frequent snapshots of a branch. Do not attempt to cherry-pick or backport individual changes, no matter how self-standing individual changes look (because they often are not).
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.
Distro maintainers for distros that require the fiction of a release should do frequent snapshots of a branch.
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.
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.
and upstream tries to exert control over downstream choices that are not properly within their purview.
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...
WrapDB policy requires upstream releases
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.
The expectation of releases is also long term support, at least of the latest release. With important fixes backported.
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.
In practice any and all change is important.
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.
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.
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 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?
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.
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.
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.
4 participants
LuaJIT/LuaJIT@04dca79...v2.1