(0031870)
Clinton Stimpson (developer)
2012-12-12 08:31

Did you notice the default value of CPACK_PACKAGE_INSTALL_DIRECTORY is "${CPACK_PACKAGE_NAME} ${CPACK_PACKAGE_VERSION}"?

If you take the defaults, it is the same.

If CPACK_PACKAGE_INSTALL_DIRECTORY is overridden, the registry key corresponds with the install location. If you have a newer installer with a newer version, but the same install location, the same registry key can be used. This avoids stale uninstall entries for older versions, if they weren't uninstalled first.

(0031871)
Eric NOULARD (developer)
2012-12-12 08:45

Concerning the "incomplete" documentation aspect
I would kindly review and possibly merge any CPack documentation patch.

Do not hesitate to submit documentation patch, then!!

(0033015)
Craig Scott (reporter)
2013-05-09 21:28

Sorry if this is somewhat hijacking this issue, but it seems relevant. Clinton's comment about a newer installer having the same registry key highlights a potential issue with the current default for CPACK_PACKAGE_INSTALL_REGISTRY_KEY. The package version is included in the default value, so a newer version will have a different registry key. Won't this mean the update mechanism for NSIS won't recognise the packages as the same with the later one being a more recent version which should replace the previous version?

(0033016)
Clinton Stimpson (developer)
2013-05-09 22:09

You highlighted the exact reason why the default is set to follow the installation directory.

cpack_set_if_not_set(CPACK_PACKAGE_INSTALL_REGISTRY_KEY
"${CPACK_PACKAGE_INSTALL_DIRECTORY}")

If the install directory of "MyProduct 1.0.0" and "MyProduct 1.0.1" both install into a directory "MyProduct 1.0", then the registry key is the same. In other words, the registry key follows the installation directory by default.

Or did I misunderstand you, and you are saying there is a problem with that?

(0033017)
Craig Scott (reporter)
2013-05-09 22:14

Probably me misunderstanding you rather than the other way around. ;) So if CPACK_PACKAGE_INSTALL_DIRECTORY is set and remains the same, installing a later version of a package should replace an earlier version? That's the behaviour we want and my earlier question was more querying whether this was indeed the current behaviour. I'd been assuming it was behaving that way but reading your comment made me second-guess myself. :b

So basically, if you never explicitly set CPACK_PACKAGE_INSTALL_REGISTRY_KEY but you do set CPACK_PACKAGE_INSTALL_DIRECTORY to the same value for all versions of your package, updates behave as expected by replacing earlier versions.

(0033035)
Clinton Stimpson (developer)
2013-05-14 00:24

3fde03c Improve documentation for CPACK_PACKAGE_INSTALL_REGISTRY_KEY.

(0034047)
Robert Maynard (manager)
2013-10-07 10:09

Closing resolved issues that have not been updated in more than 4 months.

Issue History
Date Modified	Username	Field	Change
2012-12-12 06:54	Jesus Malo Poyatos	New Issue
2012-12-12 08:31	Clinton Stimpson	Note Added: 0031870
2012-12-12 08:45	Eric NOULARD	Note Added: 0031871
2013-05-09 21:28	Craig Scott	Note Added: 0033015
2013-05-09 22:09	Clinton Stimpson	Note Added: 0033016
2013-05-09 22:14	Craig Scott	Note Added: 0033017
2013-05-14 00:24	Clinton Stimpson	Assigned To	=> Clinton Stimpson
2013-05-14 00:24	Clinton Stimpson	Status	new => assigned
2013-05-14 00:24	Clinton Stimpson	Note Added: 0033035
2013-05-14 00:24	Clinton Stimpson	Status	assigned => resolved
2013-05-14 00:24	Clinton Stimpson	Resolution	open => fixed
2013-10-07 10:09	Robert Maynard	Note Added: 0034047
2013-10-07 10:09	Robert Maynard	Status	resolved => closed

Notes
(0031870) Clinton Stimpson (developer) 2012-12-12 08:31	Did you notice the default value of CPACK_PACKAGE_INSTALL_DIRECTORY is "${CPACK_PACKAGE_NAME} ${CPACK_PACKAGE_VERSION}"? If you take the defaults, it is the same. If CPACK_PACKAGE_INSTALL_DIRECTORY is overridden, the registry key corresponds with the install location. If you have a newer installer with a newer version, but the same install location, the same registry key can be used. This avoids stale uninstall entries for older versions, if they weren't uninstalled first.

(0031871) Eric NOULARD (developer) 2012-12-12 08:45	Concerning the "incomplete" documentation aspect I would kindly review and possibly merge any CPack documentation patch. Do not hesitate to submit documentation patch, then!!

(0033015) Craig Scott (reporter) 2013-05-09 21:28	Sorry if this is somewhat hijacking this issue, but it seems relevant. Clinton's comment about a newer installer having the same registry key highlights a potential issue with the current default for CPACK_PACKAGE_INSTALL_REGISTRY_KEY. The package version is included in the default value, so a newer version will have a different registry key. Won't this mean the update mechanism for NSIS won't recognise the packages as the same with the later one being a more recent version which should replace the previous version?

(0033016) Clinton Stimpson (developer) 2013-05-09 22:09	You highlighted the exact reason why the default is set to follow the installation directory. cpack_set_if_not_set(CPACK_PACKAGE_INSTALL_REGISTRY_KEY "${CPACK_PACKAGE_INSTALL_DIRECTORY}") If the install directory of "MyProduct 1.0.0" and "MyProduct 1.0.1" both install into a directory "MyProduct 1.0", then the registry key is the same. In other words, the registry key follows the installation directory by default. Or did I misunderstand you, and you are saying there is a problem with that?

(0033017) Craig Scott (reporter) 2013-05-09 22:14	Probably me misunderstanding you rather than the other way around. ;) So if CPACK_PACKAGE_INSTALL_DIRECTORY is set and remains the same, installing a later version of a package should replace an earlier version? That's the behaviour we want and my earlier question was more querying whether this was indeed the current behaviour. I'd been assuming it was behaving that way but reading your comment made me second-guess myself. :b So basically, if you never explicitly set CPACK_PACKAGE_INSTALL_REGISTRY_KEY but you do set CPACK_PACKAGE_INSTALL_DIRECTORY to the same value for all versions of your package, updates behave as expected by replacing earlier versions.

(0033035) Clinton Stimpson (developer) 2013-05-14 00:24	3fde03c Improve documentation for CPACK_PACKAGE_INSTALL_REGISTRY_KEY.

(0034047) Robert Maynard (manager) 2013-10-07 10:09	Closing resolved issues that have not been updated in more than 4 months.

Relationships