bug#53805: 27.2; NonGNU ELPA: helm does not install dependencies

[Philip Kaludercic <philipk@posteo.net>]

Thierry Volpiatto <thievol@posteo.net> writes:

> Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <bug-gnu-emacs@gnu.org> writes:
>
>>> It seems to me that the core of the issue is that the ELPA build system
>>> overrides the existing -pkg.el files, by trying to infer all the package
>>> metadata from the main files (helm.el, helm-core.el).  If as in the case
>>> of helm and helm-core these are empty, this leads to unexpected results.
>>
>> The best course of action is to fix the upstream.
>> They simply shouldn't have any `<foo>-pkg.el` file.
>
> I disagree, in the simple case of async package this didn't cause problems, but
> here it does because we have two packages (helm-core+helm) coming from
> the same git repo.

What is the issue in this case?  The ELPAs already have packages that
share common upstream repositories.  The main issue here that I see is
that helm.el and helm-core.el don't have Package-Requires headers, which
is why the dependency list is currently empty.

>> We will generate the `<foo>-pkg.el` in any case because we include more
>> information there than what the upstream will have put (e.g. we include
>> the commit id from which the tarball is built),
>
> So what is the problem? Just append the informations fetched from the
> upstream *pkg.el files to the *pkg.el file you are usually building.
> I guess it is what Melpa does more or less.
>
>> and and modifying files that are under version control tends to lead
>> to problems.
>
> You are anyway creating a new *pkg.el file so why do you want to modify
> the original *pkg.el files?

This is also what the patch I proposed above would do.  Or rather the
-pkg file is parsed, and later overwritten.

-- 
	Philip Kaludercic