On 05/21/2018 05:46 PM, Uwe Stöhr wrote: > Am 14.05.2018 um 04:11 schrieb Richard Kimberly Heck: > >> Even *the MikTeX maintainer* has made it clear that we should not >> update MikTeX without asking permission from the user. > > Where has he stated this?
He said so in an email to Scott. Which Scott mentioned in an email to you. And which Joel, or someone else, then mentioned again, directly asking you about it. >>> Average user can misunderstand it with a probability of 50%. Those who >>> misunderstood it and denied the update can end up with an unusable LyX. >> >> No, they do not. If they deny, then NOTHING HAPPENS. > > Damn, that is not true! I am saying something very simple, and it clearly is true, so please read this carefully. If (i) you launch the installer, and (ii) the very first thing that happens is that there is a dialog telling you that, as part of installing LyX 2.3.0, we will need to update MiKTeX, and (iii) the user is given the choice either to proceed (in which case MiKTeX is updated) or to cancel (in which case the installer exits), then, if the user chooses to cancel, their installation of LyX and MiKTeX are not modified in any way. I.e., it is just as if they launched the installer, and chose "Cancel" when the licensing info was displayed. No changes are made to their system, and there is no way that anything can be broken. That is what was being proposed, and it is what I was discussing. It seems to me that you think we were proposing to give the user the option to install LyX 2.3.0 without also updating MiKTeX. I have seen that there was code, at one time, in the NSIS files, that would have asked the user whether they wanted to update MiKTeX *after* all the rest of the installation had been done, i.e., when we are about to run configure.py. I fully understand how that could cause problems. And if that is what you think I was suggesting, then I can see why you would think that a lot of what I said made no sense. But that is not what was being proposed. What was being proposed is what is above. Riki