There are package management systems for Mac OS X in use. Fink and MacPorts are the major open-source ones, and there may be others.

It would be very nice for the package managers if they could either

  1. ensure that the application they are managing uses their installation and update engine instead of the Sparkle2 engine, or
  2. simply disable Sparkle with a build-time switch.

Clearly, the first option is to be preferred.

Notes

  • I am in no way implying that Sparkle or the Sparkle developers need to know about any specific package management tool, but that Sparkle provide a documented API for writing an engine that the Sparkle framework can use to test for updates, and a per-application mechanism for changing the engine.

My plan is to make the daemon somewhat accessible to other applications, so you'll be able to do things like initiate a check for updates or register for notifications about the update process. In this case, though, I'm thinking of just having an option in the plist for whether the app should register with the daemon. MacPorts? or so on could just add that option in a script. —Andy Matuschak

I was thinking more along the lines of MacPorts? could provide a daemon that would be used instead of the Sparkle daemon that would behave the same as the Sparkle daemon--that is Sparkle would be three instead of two things:

  1. A framework for maintaining self-updating applications
  2. An update-engine that supports the framework
  3. An API for writing an update-engine that supports the framework and can co-exist with the default update-engine

I was thinking that the mechanism for knowing which update-engine to use would be stored in a .plist inside the managed bundle or application, where the default values for the .plist (and/or the absence of the .plist) would use the Sparkle update-engine, while package maintainers could insert the .plist with meaningful values for their update-engine.

I'm not sure I see it. Can you give me an example of an application of this and what the configuration might look like? —Andy Matuschak