[tex-live] Installation bug report - win7

[Lars Madsen]

the only thing I wanted to test was to see if we could provoke the same error from the installer

I would start by making a copy of the installer, such that it does not install any packages. Then we can see how it behaves when that particular system call fails, and perhaps write some good error handling for it.

Anyone know if the uninstaller can be retrofitted via tlmgr? AFAIR tlmgr and add the menu and can add the TL path to the system path (or am I remembering wrong). But I do not remember if it can also install the uninstaller.


/Lars Madsen
Institut for Matematik / Department of Mathematics
Aarhus Universitet / Aarhus University
Mere info: http://au.dk/daleif@imf / More information: http://au.dk/en/daleif@imf


________________________________________
From: tex-live [tex-live-bounces at tug.org] on behalf of Siep Kroonenberg [siepo at cybercomm.nl]
Sent: 11 December 2014 22:29
To: tex-live at tug.org
Subject: Re: [tex-live] Installation bug report - win7

On Thu, Dec 11, 2014 at 09:01:46PM +0000, Lars Madsen wrote:
> We added the path to Windows, don't remember if I used tlmgr, I tjink I did. Then pdflatex complained about missing formats. So we created the ls-r dbs and generated the formats and everything seems to be working.
>
> We are missing the menu part and I'm guessing we also miss the Uninstaller. But, the student could get on with her work.
>
> I have a virtual win7 that we could run all sorts of tests on. Isn't it possible to move one reg dB from one place to another? Regedit seems to have an import tool.

You would have to manually pick out the relevant bits: TeX-related
file associations; the TeX binary path, which may have to be
concatenated with a pre-existing user path, and the uninstaller key,
which is where the installation failed. It would only work if TeX
Live is installed in the same directory on the source- and the
target system.

The menu is not stored in the registry. Menu entries should be
created with API calls, and not copied from one system to another.

It is not clear to me what would be the best way to handle failures
during post-install. I understand that you do not want to redo the
lengthy installation of packages time and again when the real
problem occurs at the very end.

--
Siep Kroonenberg