Nicholas Vollmer

Does package.el have special casing baked in to account for this versioning scheme? How does it handle the case where package "A" requires compat "28.x.y" and package "B" requires "29.x.y"?...

> As I mentioned above, there is _no way at all_ to say you require version exactly 28.x.y, only a way to say you require _at least_ 28.x.y, therefore package.el...

> I find it hard to tell. A version bound system like in Haskell or Ruby seems like a good idea. OTOH upper version bounds are also a huge pita...

According to: https://github.com/purcell/flycheck-package/issues/11 we can't even rely on the "Version" header metadata to reliably get a package's declared version. To summarize, package-lint declares a "version" of 0 as a place...

> Packages which don't specify dependencies or versions could be excluded from the check. It's not that they don't declare a version, its that the proper declaration is not available...

> a better default might be autocrlf=false, i.e. as the repo author intended. Could this be solved via a repo-specific .gitattributes file rather than hard coding a setting into the...

>Also, as seen below, I use the latest bootstrap and switch to the develop branch in an unsuccessful attempt to prevent the native-comp-deferred-compilation-deny-list issue as documented in > https://jeffkreeftmeijer.com/emacs-native-comp-log/ The...

Related: #1062

I would encourage you to report this via `M-x report-emacs-bug` to see if it can be dealt with upstream. That will obviate the need for any such workarounds.

There are the `:pre-build` and `:post-build` recipe keywords, as well as the `straight-use-package-pre-build-functions` and `straight-use-package-post-build-functions` abnormal hooks. Are any of these suitable for what you're aiming to achieve? > what...