Re: ELPA policy

[Stephen Leake]

Filipp Gunbin <address@hidden> writes:

> On 12/11/2015 13:52 -0600, Stephen Leake wrote:
>
>> I don't see why that is different from depending on a normal ELPA
>> package.
>
> I think it's their dependants what make them different from tarball and
> normal packages.
>
> Emacs core provides API, which others use.  A normal package declares
> which versions of this API it is supposed to work against.
>
> With core packages, Emacs still provides API, but it now consists of a
> static part (C level & core) and dynamic part (core packages, which can
> later be updated from ELPA - correct me if I'm wrong).  So, a package
> should independently define which core version it works agains and which
> core package(s) version(s) it works against.

package.el dependencies can only specify a minimum version, not a
maximum. there is no way that a normal ELPA package can declare that it
works with seq.el 1.0 but not seq.el 1.1

So if emacs 25 contains a core ELPA package seq.el 1.0, the declaration

;; Package-Requires: ((emacs "25.1"))

is equivalent to:

;; Package-Requires: ((emacs "25.1") (seq "1.0))

If seq.el 1.1 is later released via the Gnu ELPA server, it will be used
in either case.

Listing a core ELPA package explicitly is only necessary when the emacs
version is less than the first version that included the core ELPA
package version.

On the other hand, it doesn't hurt, so it's probably best to recommend
listing all ELPA packages explicitly.

>>> We'll probably have to calculate and offer to user which set of the
>>> multiple core packages' multiple versions suits for multiple normal
>>> and tarball (perhaps overriden by version from Internet package
>>> archive) packages, at the same time probably giving the user to
>>> opportunity to specify her preferred version of each requested
>>> package. Is it worth the trouble? Or do I understand something wrong?
>>
>> Emacs does not support multiple versions of packages available
>> simultaneously; there is only one instance of a package that is first in
>> load-path.
>>
>> You can end up with one copy in the installed Emacs distribution, and
>> one in ~/.emacs.d/elpa. But the elpa one will take precedence; that is
>> the only one that other packages have to worry about. It either meets
>> their dependency requirement, or not.
>
> Of course, I was talking about the set of available versions which could
> be installed and from which a user or a package manager should choose.

I still don't see a problem.

We have an example of a core ELPA package now; ada-mode. version 4.3 is
in emacs git; version 5.1.8 is in ELPA (if I ever get 5.x to be fast
enough on huge files, I'll delete 4.3 from core).

package.el has no issues with this.

Similar things can occur when there are different versions of the same
package in multiple repositories. In that sense, emacs git is just
another package repository.

Can you be more explicit about what problem you foresee? Give an example
of a package that would cause a problem.

-- 
-- Stephe