Support changes in application name
Bug #228447 reported by
Andy Matuschak
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Sparkle |
Confirmed
|
Wishlist
|
Unassigned | ||
Bug Description
Sparkle fails utterly if the application's name changes at some point through its history. I think the right way to do this is that if the package to be installed is going to have an unexpected name, set some attribute in that appcast item. Needs more thought.
This ticket was migrated from the old trac: re #11
Originally reported by: andym
| Changed in sparkle: | |
| importance: | Undecided → Low |
| status: | New → Triaged |
| status: | Triaged → Confirmed |
| description: | updated |
| Changed in sparkle: | |
| importance: | Low → Wishlist |
Revision history for this message
| Hofman (cmhofman) wrote | #1 |
To post a comment you must log in.
Implementation would be pretty simple. Add a new key to the appcast for the installation filename and add support for it in SUAppcastItem. Then add a delegate method for SUInstaller to ask SUBasicUpdateDriver for this value. When it is supplied, just look for that file rather than the default guesses based on the host app's name.