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

[Thierry Volpiatto <thievol@posteo.net>]

[-- Attachment #1: Type: text/plain, Size: 1730 bytes --]


Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> 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 :-( ).

Not sure to understand this, what do you mean by unwedge? (sorry didn't
find the translation, "décoincer" perhaps?).

What I could do is creating a new file helm-core.el with only the needed
informations e.g. package-requires and add as well the package-requires
infos in helm.el, this would work for both Melpa and Elpa (after
removing the *pkg.el files).
WDYT?

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]