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

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

[Xingyu Pu]

When installing helm from the NonGNU ELPA, packages that helm requires
is not installed.

Step to reproduce:

Add nongnu repository to package-archives.
List packages by M-x list-packages.
Select helm from nongnu and install.
Package helm-core, async, popup that helm requires is not installed.

This is tested with Emacs -Q.

This is the relevant recipes copied from
"~/.emacs.d/elpa/archives/nongnu/archive-contents".
The dependecy variable is nil.
 (helm .
       [(3 6 2)
nil "Emacs incremental and narrowing framework" tar
((:url . "https://github.com/emacs-helm/helm")
(:maintainer "Thierry Volpiatto" . "thierry.volpiatto@gmail.com")
(:authors
  ("Thierry Volpiatto" . "thierry.volpiatto@gmail.com"))
(:commit . "4ff354efb6b24044fd38b725b61d470bd5423265"))])

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

[Philip Kaludercic]

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

Xingyu Pu <pu.stshine@gmail.com> writes:

> When installing helm from the NonGNU ELPA, packages that helm requires
> is not installed.
>
> Step to reproduce:
>
> Add nongnu repository to package-archives.
> List packages by M-x list-packages.
> Select helm from nongnu and install.
> Package helm-core, async, popup that helm requires is not installed.

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.

This patch seems to fix the issue on my end:


[-- Attachment #2: Type: text/plain, Size: 1356 bytes --]

diff --git a/elpa-admin.el b/elpa-admin.el
index d570c3c6aa..6714cd07a4 100644
--- a/elpa-admin.el
+++ b/elpa-admin.el
@@ -1015,14 +1015,25 @@ EXTRAS is an alist with additional metadata.
 PKG is the name of the package and DIR is the directory where it is."
   (let* ((pkg (car pkg-spec))
          (mainfile (expand-file-name (elpaa--main-file pkg-spec) dir))
+         (desc-file (expand-file-name (concat pkg "-pkg.el") dir))
          (files (directory-files dir nil "\\`dir\\'\\|\\.el\\'")))
     (setq files (delete (concat pkg "-pkg.el") files))
     (setq files (delete (concat pkg "-autoloads.el") files))
     (cond
+     ((file-exists-p desc-file)
+      (with-temp-buffer
+        (insert-file-contents desc-file)
+        (let* ((form (read (current-buffer)))
+               (pkg-desc (apply #'package-desc-from-define (cdr form))))
+          (list (= (length files) 1)
+                (package-version-join (package-desc-version pkg-desc))
+                (package-desc-summary pkg-desc)
+                (package-desc-reqs pkg-desc)
+                nil))))
      ((file-exists-p mainfile)
       (with-temp-buffer
-	(insert-file-contents mainfile)
-	(goto-char (point-min))
+        (insert-file-contents mainfile)
+        (goto-char (point-min))
         (let* ((pkg-desc
                 (unwind-protect
                     (progn

[-- Attachment #3: Type: text/plain, Size: 195 bytes --]


But it hasn't been thoroughly tested.

Another possibility I don't want to exclude is that I messed up the
package specification when adding the packages to the archive.

-- 
	Philip Kaludercic

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

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), and and modifying files
that are under version control tends to lead to problems.


        Stefan

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> 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), and and modifying files
                                                     ^
                                                    and

Sorry,


        Stefan

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

[Thierry Volpiatto]

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.

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

-- 
Thierry

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

[Philip Kaludercic]

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

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

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

[Thierry Volpiatto]

[-- 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 --]

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

"décoincer" is what I was thinking, yes.  Concretely, it means I have to
log into `elpa.gnu.org` and manually `git reset --hard` at the right
spot otherwise the cron job keeps giving me an error on the offending package.

It's due to a bug in `elpa-admin.el`, but it's one I haven't been able
to fix yet (and already "fixed it" once, so there's a chance that if
I "fix it" this time it still won't really be fixed).

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

That's the recommended way, yes.


        Stefan

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

[Thierry Volpiatto]

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


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

>>> 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?).
>
> "décoincer" is what I was thinking, yes.  Concretely, it means I have to
> log into `elpa.gnu.org` and manually `git reset --hard` at the right
> spot otherwise the cron job keeps giving me an error on the offending package.

Ok thanks.

> It's due to a bug in `elpa-admin.el`, but it's one I haven't been able
> to fix yet (and already "fixed it" once, so there's a chance that if
> I "fix it" this time it still won't really be fixed).

Ok.

>> 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?
>
> That's the recommended way, yes.

Ok, so I have applied your patch, thanks.
I have removed the emacs and async dependencies in helm.el as we already
do this in helm-core.el (as suggested in your FIXME).

-- 
Thierry

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

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

[Xingyu Pu]

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

Maybe create a new tag for that?

Thierry Volpiatto <thievol@posteo.net> 于 2022年2月7日周一 上午2:01写道：

>
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> >>> 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?).
> >
> > "décoincer" is what I was thinking, yes.  Concretely, it means I have to
> > log into `elpa.gnu.org` and manually `git reset --hard` at the right
> > spot otherwise the cron job keeps giving me an error on the offending
> package.
>
> Ok thanks.
>
> > It's due to a bug in `elpa-admin.el`, but it's one I haven't been able
> > to fix yet (and already "fixed it" once, so there's a chance that if
> > I "fix it" this time it still won't really be fixed).
>
> Ok.
>
> >> 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?
> >
> > That's the recommended way, yes.
>
> Ok, so I have applied your patch, thanks.
> I have removed the emacs and async dependencies in helm.el as we already
> do this in helm-core.el (as suggested in your FIXME).
>
> --
> Thierry
>

[-- Attachment #2: Type: text/html, Size: 2381 bytes --]

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> Ok, so I have applied your patch, thanks.
> I have removed the emacs and async dependencies in helm.el as we already
> do this in helm-core.el (as suggested in your FIXME).

Perfect, thanks,


        Stefan

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

[Pu Xingyu]

With the newest helm packages in both nongnu and nongnu-devel, 
dependencies seems to be required correctly, but now the installation 
fails with error messages: Lisp nesting exceeds ‘max-lisp-eval-depth’

Here is parted of logs from *Messages* buffer. Emacs version is 
mingw-w64-x86_64-emacs 27.2-4 on Windows.


Contacting host: elpa.nongnu.org:443
Parsing tar file...done
Extracting...done
   INFO     Scraping files for helm-core-autoloads.el...
Generating autoloads for helm-core-pkg.el...done
Generating autoloads for helm-core.el...done
Generating autoloads for helm-lib.el...done
Generating autoloads for helm-multi-match.el...done
Generating autoloads for helm-source.el...done
Generating autoloads for helm.el...done
   INFO     Scraping files for helm-core-autoloads.el...done
Wrote 
c:/Users/stshi/.emacs.d/elpa/helm-core-3.8.4.0.20220210.74849/helm-core-autoloads.el 
[2 times]
package-built-in-p: Lisp nesting exceeds ‘max-lisp-eval-depth’


在 2022/2/7 1:57, Thierry Volpiatto 写道:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>>> 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?).
>> "décoincer" is what I was thinking, yes.  Concretely, it means I have to
>> log into `elpa.gnu.org` and manually `git reset --hard` at the right
>> spot otherwise the cron job keeps giving me an error on the offending package.
> Ok thanks.
>
>> It's due to a bug in `elpa-admin.el`, but it's one I haven't been able
>> to fix yet (and already "fixed it" once, so there's a chance that if
>> I "fix it" this time it still won't really be fixed).
> Ok.
>
>>> 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?
>> That's the recommended way, yes.
> Ok, so I have applied your patch, thanks.
> I have removed the emacs and async dependencies in helm.el as we already
> do this in helm-core.el (as suggested in your FIXME).
>

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> With the newest helm packages in both nongnu and nongnu-devel, dependencies
> seems to be required correctly, but now the installation fails with error
> messages: Lisp nesting exceeds ‘max-lisp-eval-depth’

Oops, indeed, sorry, packaging bug.  I believe it is fixed now in
`nongnu` (will fix itself in `nongnu-devel` on the next commit).


        Stefan

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

[Pu Xingyu]

Helm from NonGNU seems to be working fine now, This bug can be closed.

Thanks to you maintainers!

在 2022/2/11 0:35, Stefan Monnier 写道:
>> With the newest helm packages in both nongnu and nongnu-devel, dependencies
>> seems to be required correctly, but now the installation fails with error
>> messages: Lisp nesting exceeds ‘max-lisp-eval-depth’
> Oops, indeed, sorry, packaging bug.  I believe it is fixed now in
> `nongnu` (will fix itself in `nongnu-devel` on the next commit).
>
>
>          Stefan
>

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Pu Xingyu [2022-02-12 01:49:42] wrote:
> Helm from NonGNU seems to be working fine now, This bug can be closed.

Thanks for confirming,
Closing,


        Stefan

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

[Thierry Volpiatto]

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


Philip Kaludercic <philipk@posteo.net>, Thierry Volpiatto <thievol@posteo.net> writes:

> 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

There is no helm-core.el file.

> don't have Package-Requires headers, which is why the dependency list
> is currently empty.

Since long time I asked to not have such informations fetched from
source files but from pkg.el files, which is cleaner.
 
>>> 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.

Looks good.

-- 
Thierry

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

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> 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
> There is no helm-core.el file.

Then create one.  It doesn't need to hold anything else than the usual header.
[ Tho, in NonGNU ELPA we work around this currently by telling to use
  `helm.el` instead.  ]

IOW I suggest the patch below (which also fixes some inconsistencies
between the info in `helm.el` and in `helm-pkg.el`).

BTW, is "Development files for Helm" really a good description?
To me it would indicate that it's a package with a similar role to
Debian's <foo>-dev packages, i.e. a package only needed if you're
developing code for Helm, rather than if you merely use the Helm tools.


        Stefan


diff --git a/.gitignore b/.gitignore
index 46bc97419b..e734827684 100644
--- a/.gitignore
+++ b/.gitignore
@@ -3,5 +3,8 @@ patch*
 *.patch
 *.diff
 TAGS
-helm-autoloads.el
+/helm-autoloads.el
+/helm-core-autoloads.el
+/helm-pkg.el
+/helm-core-pkg.el
 ID
diff --git a/helm-core-pkg.el b/helm-core-pkg.el
deleted file mode 100644
index 9ea9fbaaaf..0000000000
--- a/helm-core-pkg.el
+++ /dev/null
@@ -1,11 +0,0 @@
-;;; helm-core-pkg.el --- define helm-core for package.el
-
-(define-package "helm-core" "3.8.4"
-  "Development files for Helm"
-  '((emacs "25.1")
-    (async "1.9.4"))
-  :url "https://emacs-helm.github.io/helm/")
-
-;; Local Variables:
-;; no-byte-compile: t
-;; End:
diff --git a/helm-core.el b/helm-core.el
new file mode 100644
index 0000000000..861492eece
--- /dev/null
+++ b/helm-core.el
@@ -0,0 +1,33 @@
+;;; helm-core.el --- Development files for Helm  -*- lexical-binding: t; -*-
+
+;; Copyright (C) 2022  Thierry Volpiatto
+
+;; Author: Thierry Volpiatto <thierry.volpiatto@gmail.com>
+;; URL: https://emacs-helm.github.io/helm/
+;; Version: 3.8.4
+;; Package-Requires: ((emacs "25.1") (async "1.9.4"))
+
+;; This program is free software; you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; This program is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with this program.  If not, see <https://www.gnu.org/licenses/>.
+
+;;; Commentary:
+
+;; This is just a place holder we currently use only to hold the package's
+;; metadata in the header.
+
+;;; Code:
+
+
+
+(provide 'helm-core)
+;;; helm-core.el ends here
diff --git a/helm-pkg.el b/helm-pkg.el
deleted file mode 100644
index 6d0a91c5d5..0000000000
--- a/helm-pkg.el
+++ /dev/null
@@ -1,13 +0,0 @@
-;;; helm-pkg.el --- define helm for package.el
-
-(define-package "helm" "3.8.4"
-  "Helm is an Emacs incremental and narrowing framework"
-  '((emacs "25.1")
-    (async "1.9.4")
-    (popup "0.5.3")
-    (helm-core "3.8.4"))
-  :url "https://emacs-helm.github.io/helm/")
-
-;; Local Variables:
-;; no-byte-compile: t
-;; End:
diff --git a/helm.el b/helm.el
index f54e193344..fbf4637d94 100644
--- a/helm.el
+++ b/helm.el
@@ -1,7 +1,4 @@
-;;; helm.el --- Emacs incremental and narrowing framework -*- lexical-binding: t -*-
-
-;; Version: 3.8.3
-;; URL: https://github.com/emacs-helm/helm
+;;; helm.el --- Helm is an Emacs incremental and narrowing framework  -*- lexical-binding: t -*-
 
 ;; Copyright (C) 2007         Tamas Patrovics
 ;;               2008 ~ 2011  rubikitch <rubikitch@ruby-lang.org>
@@ -14,7 +11,11 @@
 ;;                         Thierry Volpiatto <thierry.volpiatto@gmail.com>
 
 ;; Author: Thierry Volpiatto <thierry.volpiatto@gmail.com>
-;; URL: http://github.com/emacs-helm/helm
+;; Version: 3.8.4
+;; URL: https://emacs-helm.github.io/helm/
+;; FIXME: The `emacs' and `async' requirements are already satisfied by
+;; `helm-core', so maybe we don't need them here?
+;; Package-Requires: ((emacs "25.1") (async "1.9.4") (popup "0.5.3") (helm-core "3.8.4"))
 
 ;; This program is free software; you can redistribute it and/or modify
 ;; it under the terms of the GNU General Public License as published by