Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MiKTeX setup on Windows 10 not working #884

Closed
rpspringuel opened this issue Feb 6, 2016 · 4 comments
Closed

MiKTeX setup on Windows 10 not working #884

rpspringuel opened this issue Feb 6, 2016 · 4 comments

Comments

@rpspringuel
Copy link
Contributor

It appears that on Windows 10 the post-install script which sets up the texmf tree is not run with administrator rights, even when the installer was invoked with them. The result is that the post-install script errors on the line local p = os.spawn("initexmf -u --admin") because the --admin option for initexmf requires admin privileges.

After some experimentation, I've found two possible ways to fix this:

  1. Simply remove the --admin option. Based on my testing this appears to work most of the time, but I occasionally run into problems where initexmf is unable to rebuild the fndb because the file is locked by another process (presumably a MiKTeX one, though I can't find the process causing the problem). This is a somewhat irregular error. Fixing it means getting MiKTeX to release that lock by playing with the Settings Manager or the Updater, or by deleting the fndb manually and then building them from scratch.
  2. In addition to removing the --admin option, we also don't copy the GregorioTeX files into TEXMFLOCAL. Instead we take advantage of MiKTeX's ability to register arbitrary texmf roots to register the folder actually placed by the installer. Since this is a new folder, there is not fndb associated with it so any existing file locks will not affect the building of its fndb (the error might show up when it tries to rebuild the fndb for one of the other registered texmf roots, but it still builds the new one). This would have the added advantage of meaning that when a user uninstalls Gregorio, we leave less of a footprint behind (just the copy of gregorio.exe which was copied to a PATH location).

The second solution is more complicated, but in my testing thus far also more reliable. However, it also marks a departure from the installation procedure on other systems. As best I can tell, MiKTeX is the only TeX distribution which enables the user to easily register new texmf tree roots. On TeXLive distributions doing so requires manually editting texmf.cnf to change the definition of TEXMFLOCAL. I could, of course, script this process, but it would not be the "normal" way to do this (we already do things the "normal" way).

What are other people opinions on this issue? Should we favor the more usual but slightly less reliable installation method, or the more reliable but more idiosyncratic one for MiKTeX?

@henryso
Copy link
Contributor

henryso commented Feb 6, 2016

I vote more reliable. It would mean fewer support requests.

@eschwab
Copy link
Contributor

eschwab commented Feb 6, 2016

2 sounds like a better option. I like the idea of leaving a clean(er) system after uninstalls.

@eroux
Copy link
Contributor

eroux commented Feb 6, 2016

Indeed, second option sounds better, but option1 would be enough for beta2? I just got the go for branch fix-858, so I'll make a proper pull request tomorrow and maybe we can release beta2 afterwards?

@eroux
Copy link
Contributor

eroux commented Feb 8, 2016

I guess it can be closed, reopen if necessary

@eroux eroux closed this as completed Feb 8, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants