> > In other words, no particular thought was given to -pkg.el. It was > > simply dropped along with many other files. So, if consensus is > > reachedthat keeping -pkg.el is a good idea, there is no reason to not > > do that. > Thanks for clearing that up. In that case, I don't have any qualms > about including them either.
Cool, seems we can get -pkg.el files back. > 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). Yep, the last snippet supports multi-profile Emacs. Installing packages for Emacs via a few different package manager sounds like a very bad practice) I agree that current implementation with updating variables isn't perfect and it doesn't cover the use case, which I expect to be rare (packages from Guix will be listed in list-packages, files from foreign distro PM won't). I can dive into package.el implementation and spend some time next week providing a different workaround. BTW, can you remind me why we do not place packages under site-lisp/elpa/NAME-VERSION? It seems almost the same as site-lisp/NAME-VERSION, but everything related to describe-package and other functions will work out of the box. This way it will work even with a foreign distro use case.