bug#18448: Problems installing (M)ELPA packages

[Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>]

Hello,

(This discussion was started on gnu.emacs.help)

Michael Heerdegen wrote:
> Stefan Monnier wrote:
>> Sebastien Vauban wrote:
>>>
>>> While using `package.el' fulfills a long-awaited dream for easily adding
>>> and upgrading Emacs libraries, I now feel upgrading packages is much
>>> more complex than what I anticipated.
>>>
>>> At least two of the packages I use daily (Org and Helm) require to be
>>> installed from inside a fresh Emacs session (emacs -Q), where nothing
>>> has been loaded.
>>>
>>> For example, the FAQ entry from Helm on this:
>>>
>>>   ╭──── https://github.com/emacs-helm/helm/wiki#ihaveupdatedfrommelpaandihaveerrors
>>>   │
>>>   │ I have updated from melpa and I have errors
>>>   │
>>>   │   - Uninstall helm from list-packages
>>>   │   - Close emacs
>>>   │   - Start emacs -Q
>>>   │   - Reinstall helm from list-packages
>>>   │   - Restart emacs
>>>   ╰────
>>>
>>> I guess a lot of people are not aware of this, and don't take enough
>>> look at the Compile log to see that it can lead to (big?) problems.
>>>
>>> Is that something that could/will be fixed in the future?
>>>
>>> Is the Helm workaround (with Emacs-async, documented in the above link)
>>> usable for avoiding this with all ELPA packages?
>>
>> There have been some discussions about it in emacs-devel, but nothing
>> concrete came out of it yet (except maybe emacs-async, tho IIUC it
>> existed before).
>>
>> I suggest you re-start a discussion about this in emacs-devel or via
>> M-x report-emacs-bug.
>>
>> For this discussion, it would be helpful to have a list of known
>> breakages with some analysis of why they break.  I know of one source of
>> problems:
>> When compiling the new package, (require 'foo) will do nothing if the
>> old package also had a `foo' which is already loaded, in which case we
>> end up using the old package's `foo' to compile the new package, which
>> of course leads to various problems, e.g. if we use some macros from `foo'.
>
> For helm, that is exactly the problem (and the only one I know of).
> Currently, the maintainers are flooded with breakage reports due to
> macro changes.
>
> AFAICT, it is planned to enhance async so that it can perform
> compilation of packages (and to use an advice to make package.el use
> it.).  For helm, it is planned to let the helm package depend on
> emacs-async, which should solve the problem - see
>
> https://github.com/emacs-helm/helm/issues/617.

I don't know/understand the cause for Org, but installing Org mode in
a session where Org is already loaded will lead to
`org-with-silent-modification' "invalid function" errors (there are
a lot of such posts about it in the mailing list).

Best regards,
Seb