I was looking a the source to bdist_msis - it doesn't seem there's any way
to tell it to add extra properties, but it seems it uses the "msilib" module
http://docs.python.org/lib/module-msilib.html to do all the msi work.
So I wrote a script that uses msilib to add the property, it's attached, I
verified the property is added with Microsoft's Orca msi editing tool. I
tested the installer after modification, and it went ahead and replaced all
files even ones I had modified, so the property seems to work. I think if it
were integrated into pygame's setup.py as some bdist_msi post installer
step, it should solve the problem.
... I'd go ahead and make a patch, but I don't know how to figure out the
name of the installer that's created in Setup.py... anybody know how to get
that from the bdist command or something?
----
... as a note about testing though - for some reason windows caches msi
files based on some magic ID in them, so if you run an msi installer, then
change the properties (like with this script) on that installer, when you
run the installer again, it won't use the new properties cause it cached it
when you first ran it... yet if you add a "v" to the REINSTALLMODE string,
then windows won't use it's msi cache. So amus is fine for new installers
you build, but you need to use vamus or vomus in testing changes to your
install if you've already ran it. Weird.
On Sun, May 25, 2008 at 12:55 PM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote:
> Thanks, I can try the REINSTALLMODE property. I looked into msi earlier for
> the documents and examples. It is more complicated than just checking file
> timestamps. I haven't had a chance to look at it again lately. But if I
> remember correctly setting a property is not too difficult. The challenge
> will be getting around the machinery of distutils.
>
> Lenard.
>
>
> Brian Fisher wrote:
>
>> It looks like msi has some rules about file replacing files intended to
>> make it so it doesn't replace stuff modified by the user and doesn't replace
>> user's files that are newer than what's being installed - here's a random
>> page written by some random person that seems to describe them:
>>
>> http://juice.altiris.com/tip/3923/how-files-are-overwritten-windows-installer-service
>>
>> I think the SDL files would be considered versioned, and none of the
>> pygame files would be considered versioned.
>>
>> ...It seems we'd want to completely turn that behavior off... if I
>> installed pygame 1.7 for instance, I'd expect it to clobber 1.8, it's my own
>> choice to downgrade - but the default behavior of msi is to successfully
>> "install" but then do nothing
>>
>> evidentally there is some "REINSTALLMODE" property that controls this
>> stuff - I guess the default is "omus" where the o means replace older only.
>> I guess we'd want "amus" where a means to replace all files. Here's another
>> random page about that:
>> http://juice.altiris.com/tip/2904/controlling-file-version-settings
>>
>> .... so provided that's all right - the next obstacle would be customizing
>> something with bdist_msi... does anybody know how we might change a
>> "property" when using bdist_msi? or maybe how to change properties after
>> creating the file?
>>
>> On Wed, May 21, 2008 at 10:20 PM, Lenard Lindstrom <[EMAIL PROTECTED]<mailto:
>> [EMAIL PROTECTED]>> wrote:
>>
>> When I try this for Python 2.4 I find nothing is replaced. Only
>> files new to Pygame 1.8 are added. Consequently I don't get the
>> error since it is still effectively Pygame 1.7. The msi installer
>> is generated entirely by distutils. To customize its behavior
>> means more hacks to distutils. We could always go back to the
>> distutils executable Windows installer. What I know is msi is
>> demanding. You must design your project around it for it to work
>> as intended. Also the msi module included with Python 2.5 is
>> inflexible.
>>
>> Lenard
>>
>>
>> Brian Fisher wrote:
>>
>> So does anybody know why exactly this problem happens? Is
>> there some file left behind by 1.7.1 that is not replaced with
>> a 1.8.0 file? If so, what file?
>>
>> On Wed, May 21, 2008 at 4:12 PM, René Dudfield
>> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
>> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote:
>>
>> hey,
>>
>> I've made a note about uninstalling pygame 1.7.1 first on the
>> download page...
>>
>> However I think we need to figure out how to get the
>> windows installer
>> to check if pygame is installed already... and if so
>> uninstall it. Or
>> if we can't do that, make it display instructions to
>> uninstall in the
>> installer (maybe by putting it in the README).
>>
>>
>>
>>
>
import msilib
msi_filename = "pygame-1.8.1a0.win32-py2.5.msi"
db = msilib.OpenDatabase(msi_filename, msilib.MSIDBOPEN_TRANSACT)
msilib.add_data(db, "Property", [("REINSTALLMODE", "amus")])
db.Commit()
