You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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?
The text was updated successfully, but these errors were encountered:
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?
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 forinitexmf
requires admin privileges.After some experimentation, I've found two possible ways to fix this:
--admin
option. Based on my testing this appears to work most of the time, but I occasionally run into problems whereinitexmf
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.--admin
option, we also don't copy the GregorioTeX files intoTEXMFLOCAL
. 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 aPATH
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 ofTEXMFLOCAL
. 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?
The text was updated successfully, but these errors were encountered: