Am Donnerstag, den 20.05.2021, 13:01 +0300 schrieb Andrew Tropin: > > That looks like it'd mess with people's installed ELPA > > packages. In general, hacks based on package-directory-list don't > > feel very stable. > > If you talk about ~/.emacs.d/elpa, it won't, because there is a > separate package-user-dir variable for that. > > The problem can arise if we have emacs installed in a few profiles, > I'm not sure if it is a good idea to do so, but it is possible, in > such a case we will have a few items in the package-directory- > list. A fix for that: > > (setq package-directory-list > (mapcar (apply-partially 'string-remove-suffix "/elpa") > package-directory-list))) Multi-profile Emacs should be supported, but this also breaks on foreign distros with foreign distro ELPA. Again, hacking variables is not the solution (and even if it was, it'd be better to patch the emacs default value, not that this is a good idea either).
> > Also, this seems to rely on us not deleting the -pkg.el, but > > probably won't work for packages, that don't ship it, e.g. emacs- > > howm. > > It's true, but it seems relatively easy to implement a build phase, > which will generate -pgk.el in case it is missing. Generating our own -pkg.el should work, still waiting for Maxim or Arun on a statement as to why we exclude it. *Always* generating a -pkg.el (disregarding the upstream one if it exists) might further be a reasonable thing to do if we decide, that those -pkg.el files are useful. Regards, Leo