Re: Supporting multiline Package-Requires header

[Artur Malabarba <bruce.connor.am@gmail.com>]

>> I suggest keeping what we have actually for backward compatibility a
>> generalize the use of a *-pkg.el file with a define-package form even
>> for single file packages.
>
> I think actually, you have hit the nail on the head here.
>
> As others have pointed out, while this change is backward compatible
> (for package.el) actually using the format in a package is not backward
> compatible with older Emacs'.

As with any new feature.

> The package author can specify the minimal Emacs version, of course, but
> unfortunately this happens in the "Package-Requires:", which will be
> parsed incorrectly in older Emacs'.

Before a package is installed, the header is not being parsed by the
user's computer, it is being parsed by the archive's server (be it
Gelpa, Melpa or Marmalade). The archive's server should be using
latest Emacs, and they'll know that the package requires Emacs 25, and
they'll provide that information to the user during `list-packages'.
(Even if the archive is using Emacs 24, or if the user tries to
manually install the package, they'll be immediately greeted with an
error, telling them something is wrong.)

> Instead of making Package-* headers more capable, deprecating them in
> favour of *-pkg.el files (which really is a sexp, has to balance, but is
> easy to check for balance) makes quite a lot of sense.

I'm not strongly against this, but I think it would be more of an
annoyance than a benefit. I've never run into problems because of the
fact that we use lisp headers for package information, so I don't see
why we'd deprecate them.

> Probably easier when you get right down to it.

Easier than what? Extending the Package-Requires header would be
something like 3-6 lines of code.