Steve Purcell <steve@sanityinc.com> writes:

> >> Nonetheless, it has been part of the format expected by package.el for years.
> >>
> >> Making package.el more permissive over time can lead to problems with packages
> >> in older Emacsen, a prime example being the recently-added
> >> backwards-incompatible support for version-less dependencies in the
> >> `Package-Requires` header: authors check their packages in a recent Emacs and
> >> then find that an older otherwise-compatible Emacs can’t even parse their
> >> package metadata.
> >
> > Sure, that can be a problem.  I think that means that we should not
> > (yet) encourage package developers to not use them in their packages.
> > But if we don't take a first step, we can never get rid of it.
>
> > At the end of the day, it's the job of package developers to maintain
> > backwards compatibility.  I don't see why this change would be any
> > different in that respect from the many other changes that we make
> > between releases.
>
> My point is that if a package file can’t even be parsed by an older Emacs
> version’s “package.el”, the user of that Emacs version will automatically get an
> obscure error when they try to install it, even if the the package author was
> helpful enough to add `(emacs “27”)` as a dependency to indicate
> incompatibility. That’s not something that the package author could reasonably
> foresee, and it feels avoidable by keeping the basic structure of required
> metadata stable and backwards compatible.

I see your point.  How about issuing a warning instead?  That should
be sufficiently discouraging for package authors, while also allowing
us to drop this requirement at some point in the future.

I've attached a patch which I believe would do this in a reasonable way.

Best regards,
Stefan Kangas