Philip Kaludercic , Thierry Volpiatto writes: > Thierry Volpiatto writes: > >> Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of >> text editors" 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 `-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 `-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