Mworks MWorks Supporting Components → 0.4.4

Comments and changes to this ticket

• 

  Christopher Stawarz May 11th, 2010 @ 03:18 PM

  • Milestone set to “0.4.4”
• 

  Christopher Stawarz May 11th, 2010 @ 03:20 PM

  • Assigned user set to “Christopher Stawarz”
• 

  David Cox May 11th, 2010 @ 03:50 PM

  I think that this is a property of your new installer, not the "standard" one. The regular one has been happily installing over old installs for years. Just tested installing an old version over top of a new one on my system, and it works as expected. Unless I'm not understanding what the symptom is.

• 

  Christopher Stawarz May 11th, 2010 @ 05:00 PM

  If I run the MWorks installer, drag MWServer.app from /Applications to my desktop, and then run the installer again, I see the following in /var/log/install.log:

  Applications/MWServer.app relocated to Users/cstawarz/Desktop/MWServer.app
  PackageKit: Registered bundle file://localhost/Users/cstawarz/Desktop/MWServer.app/
  

  I just tried this with both my installer and yours and got the same result.

  However, I was partly wrong in my initial report, as it turns out that the installer does in fact overwrite the contents of Desktop/MWServer.app with the new files. Maybe it's trying to respect the user's decision to move the app bundle to a non-standard location?

  Here's the problem I see: If a user archives their current installation of MWorks, say by moving the apps and frameworks to ~/Documents/Old MWorks, before installing a new version, the installer will overwrite the backed-up apps with the new ones, thereby both destroying the backup and confusing the user by not installing the new apps in /Applications. Unfortunately, I'm no longer sure that changing CFBundleVersion will solve the problem.

• 

  David Cox May 11th, 2010 @ 06:08 PM

  Maybe we could just zip the archive?

• 

  David Cox May 11th, 2010 @ 06:12 PM

  Actually, what if you copy instead of move? I've seen OS X watch the filesystem node instead of the file path in other contexts. If you copy, it will create a new node, so it is possible at this could help.

• 

  Christopher Stawarz May 12th, 2010 @ 11:25 AM

  Zipping the archive is probably the most robust solution. But I'll try copying, too, just to see what happens.

• 

  Christopher Stawarz May 13th, 2010 @ 01:39 PM

  • Milestone cleared.
  • State changed from “new” to “invalid”

  I've now tried copying the application instead of moving it, as well as incrementing CFBundleVersion between installations. In both cases, the installer still overwrites the existing copy of the app (in this case, ~/Desktop/MWServer.app).

  Since the installer does actually install the new version, I'm going to mark this ticket invalid. However, I'll add a note to this ticket about zipping the archive.

• 

  Christopher Stawarz May 20th, 2010 @ 06:45 PM

  It looks like you can prevent this behavior by passing the option --no-relocate to PackageMaker. I've added this to new_installer/build_installer, and the generated installer now ignores the existing MWServer and installs the new one in /Applications. Nice!

• 

  Christopher Stawarz April 17th, 2012 @ 01:50 PM

  • State changed from “invalid” to “resolved”
  • Milestone set to “0.4.4”
  • Milestone order changed from “0” to “0”