This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author jasonjroberts
Recipients brian.curtin, eric.araujo, francisco, jasonjroberts, loewis, mhammond, tarek
Date 2011-11-30.16:54:07
SpamBayes Score 0.0
Marked as misclassified No
Message-id <1322672047.77.0.617287815745.issue13276@psf.upfronthosting.co.za>
In-reply-to
Content
Sorry, I opened issue13509 after somehow not finding this one. Here is my text from issue13509. Thanks for looking at this problem...

Historically (i.e. Python 2.6.1 and earlier) bdist_wininst would run the post install script at both installation and uninstallation. The script would be invoked with a -install argument on installation and a -remove argument on uninstallation. This stopped working in Python 2.6.2 and has not worked since.

This regression appears to have been introduced in r69094. That checkin rewrote Run_RemoveScript and associated functions in PC/bdist_wininst/install.c. The rewrite changed how the Python DLL was loaded during the remove scenario.

Previously Run_RemoveScript itself called Win32 LoadLibrary on the DLL name parsed from the wininst log file. Now Run_RemoveScript calls run_installscript instead, which ultimately calls LoadPythonDll, which calls LoadLibrary on the pythondll global variable. But nothing initializes that variable during the remove scenario and LoadLibrary fails. Ultimately run_installscript silently fails and the removal proceeds to uninstall files and registry keys, with no notification to the user that the post install script was not run.

A possible solution is to initialize pythondll in Run_RemoveScript to the DLL name parsed from the wininst log file, e.g. by inserting the following code prior to the call to run_installscript:

        strncpy(pythondll, dllname, scriptname - 1 - dllname);
        pythondll[scriptname - 1 - dllname] = '\0';

I tested this and it seemed to work fine.

I believe this problem affects all Python releases following and including 2.6.2. The version history seems to show that r69094 was propagated to all of those releases. Presumably nobody found it because post install scripts on removal are not widely used. They are, however, critical for my application (at least if I want it to clean up properly on removal) so I would appreciate this being fixed. As it stands, I have to build a private patched copy of wininst-9.0.exe to work around this problem.
History
Date User Action Args
2011-11-30 16:54:07jasonjrobertssetrecipients: + jasonjroberts, loewis, mhammond, tarek, eric.araujo, brian.curtin, francisco
2011-11-30 16:54:07jasonjrobertssetmessageid: <1322672047.77.0.617287815745.issue13276@psf.upfronthosting.co.za>
2011-11-30 16:54:07jasonjrobertslinkissue13276 messages
2011-11-30 16:54:07jasonjrobertscreate