If there's another version of our app on the volume, it'll relocate the installed one there. This is particularly delightful, since nothing will work if it's not in /Applications.
We use pkgbuild and productbuild to create the .pkg file.
It is possible to use pkgbuild without --component-plist, it looks like you are doing that. If you want more control, run pkgbuild with the --analyze option, then edit the template plist to your liking (this is where you could make the app bundle non-relocatable), and subsequently use pkgbuild with --component-plist.
It has been forever since I did this, so this is as far as I think I could assist. I hope it helps.
Does your component.plist contain
<key>BundleIsRelocatable</key>
<true/>
If so, changed it to <false/>.
I thought this (BundleIsRelocatable=true) meant that the user can change the destination. In fact, it means that the Installer can relocate the bundle to the location of a previously-installed bundle, rather than put it at RootRelativeBundlePath
I don't think we have the .plist file. We use
pkgbuild --identifier org.${PRODUCT}.${VERSION} \
--version ${VERSION} \
--scripts "${TARGET_DIRECTORY}/darwin/scripts" \
--root "${TARGET_DIRECTORY}/darwinpkg" \
${TARGET_DIRECTORY}/package/${PRODUCT}.pkg > /dev/null 2>&1
productbuild --distribution "${TARGET_DIRECTORY}/darwin/Distribution" \
--resources "${TARGET_DIRECTORY}/darwin/Resources" \
--package-path "${TARGET_DIRECTORY}/package" \
"${TARGET_DIRECTORY}/pkg"/$1 > /dev/null 2>&1
It is possible to use pkgbuild without --component-plist, it looks like you are doing that. If you want more control, run pkgbuild with the --analyze option, then edit the template plist to your liking (this is where you could make the app bundle non-relocatable), and subsequently use pkgbuild with --component-plist.
It has been forever since I did this, so this is as far as I think I could assist. I hope it helps.
Finally did that, experimented with trimmed down the .plist file to only have the minimal keys, and voila, Bob's my uncle! Thank you 😄