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

[Stefan Monnier]

>> 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.

I don't see in which way it makes a difference.
For the `helm-core` package, the info will be fetched from the headers
of `helm-core.el`.

>> 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?

The problem is not fundamental, but since the scripts we have generate
the `<pkg>-pkg.el` file in place, it means we end up with a dirty Git
clone where some of the tracked files have been locally modified, so
later operations like `merge` can get spurious conflicts.

The scripts try to handle those problems by cleaning after themselves,
but apparently not well enough because I've already had to go and
manually unwedge the system for a few packages that have their own
`<pkg>-pkg.el` file (`helm` and `helm-core` being among those I've had
to manually unwedge :-( ).

>> 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?

Since it works in place, there is no difference between "creating a new
*pkg.el file" and "modify the original *pkg.el files".


        Stefan