Can a .pkg replace an application bundle with a different name? - macos

In the previous Mac release of our software, we foolishly put the major version number in the application bundle name: /Applications/CellProfiler2.0.app
Now we are about to release version 2.1. Is it possible to have pkgbuild make a .pkg package that installs the new version as /Applications/CellProfiler.app but removes the old /Applications/CellProfiler2.0.app?

It is; and in fact, You have, as we see it, two options here:
1) Use pre-install scripts in the pkg to either detect your old version and ask the user to remove it, or remove it yourself (or first just rename the directory to be without the 2.0)
2) Package your installer in a DMG, and run the installer as a separate file altogether, and do either of the above.

Related

Installing two different yt versions in two different directories

I am using yt 3.1 on a cluster and the current version is installed in a directory /work/../../sw/yt-3.1/yt-x86_64/bin/yt , now I would like to try the new version 3.3.1 but I still want to use the older version in parallel to compare. Please let me know what is the procedure to get a different version in a different directory.
Just run the latest version of the install script in a folder like /work/../../sw/yt-3.3. The install script creates an isolated environment that is entirely contained in the installation folder.
Keep in mind that the install script was updated for yt 3.3 to build a conda environment by default. This makes the install script run much more quickly and is also more robust on most machines, particularly ones with old or nonexistent OpenSSL installs. If you want to make the install script build everything from source like it did for yt 3.1, set INST_YT_SOURCE=1 and INST_CONDA=0 in the install script.

How to Force install location from OSX .pkg

I'm attempting to create a package installer for our product. Previously we installed with a .dmg, and the process was to just drag it to the /Applications folder. Now we want it to install to /Application/Company/Suite/product.
Problem is: If we use the .pkg installer on a system that previously had our product installed it creates the folders, but installs the product over the old location.
How can I make the pkg installer do the following:
Remove the old version
Install new version to proper location
I've had very little experience with OSX - so maybe I'm just missing something? Also looking in the applications folder - it doesn't appear that anything else is installed to a subdirectory, is it unusual to do things this way?
Thank you!
EDIT:
I'm looking into the answers located here OSX .pkg installer sometimes does not install .app file, differently worded problem - but the answer might be just what I need.
EDIT2: OSX .pkg installer sometimes does not install .app file Does not apply. We didn't install with any package manager - so there isn't a previous entry.
EDIT3: We were using dmg, but are now moving to pkg.
So I found the answer.
In order to have it install to a new location:
The plist inside the app package (product.app/Contents/Info.plist) has an identifier "CFBundleIdentifier", these needs to be different from the old application. For instance ours was "Company.Product-Name", I've changed it to "Company.Product.Name". This will allow the new installation to go to the new location.
In order to remove the old installation:
I simply added this line to the preinstall script:
"sudo rm -Rf '/Application/Product Name.app'"
Thank you for your assistance.

How to uninstall old OSGI bundle version upon installation of a new version?

I am using the CQ Blueprints maven archetype for Adobe CQ to deploy OSGi bundles into CQ5.6.1. This archetype uses the Maven Sling Plugin to deploy the bundles by copying them into an install directory of my content repository.
I am changing the version numbers of my bundles upon every build using the maven versions plugin. Therefore, upon each deployment, a bundle jar with a new filename is installed, like commons-services-1.0.30.jar. My problem is, currently the older bundle versions, like commons-services-1.0.29.jar, are not removed upon installation of a newer version.
I would like to avoid old bundle versions piling up in my install folders. Therefore my question is: What is the best way to uninstall/delete these older versions upon installation of a new version?
Bundles piling up in an install folder are not really a problem - they will only use the space, but they are ignored by the Apache Sling OSGI installer that CQ uses to detect and install the bundles. The installer only considers the latest version of the bundle (based on its OSGi version header), and ignores older versions.
If you really want to remove the older bundle files, best is probably to create a small tool that finds them by walking the JCR tree under which they are installed (/apps I assume), and delete all but the latest version. If the bundle filenames consistently include the version number you can probably just sort their names with the right comparator and remove all but the last one. If you want to be really robust you'll need to read the bundle metadata to find out about its version number.
If you want to run your tool automatically at regular intervals you could register an OSGi EventHook to detect when new bundles are installed, and trigger a cleanup run when that happens.
Sorry if this sounds a bit complicated - but again leftover bundle files are not really problematic.
I solved the problem by configuring the filter.xml in my myproject-all module (see CQBlueprints description for the purpose of this module) to delete the contents of my bundle install folder. This way, old bundles are always deleted before new bundles are installed.
To delete the contents of my install folder, I added the following line to my filter.xml file:
<filter root="/apps/myapp/install">
use curl command to delete the specific bundle version.
curl -u admin:admin -daction=uninstall http://localhost:4505/system/console/bundles/"name of bundle"
Edit: Removed purging as that was not applicable to the osgi bundle.

How to create upgrade package using iceberg for mac

I have created a installation package for mac os x using iceberg, which was successful and working fine.
But i have many version of my application.
So My question is how to make a upgrade package using iceberg?,
During upgrade some of the directories inside the installation directory should be untouched(not to be replaced)
In your installer, leave out the directories which shouldn't be touched and they will be ignored. I've noticed that existing directories and files not targeted with changed/added bits aren't touched.

How do I force Inno Setup to make the 'uninsneveruninstall' flag retroactive?

Inno Setup keeps an "Uninstall log" file unins000.dat in the application's install directory. This file contains a list of all the files that are to be uninstalled when the application is removed. When a new version of the app is installed over the old one, Inno Setup just appends any new files to the "Uninstall Log".
An early version of my application removes some user-modified template files when it is uninstalled, because I forgot to include the uninsneveruninstall flag for those files.
In the latest version of the software, the uninsneveruninstall flag is set, and the files don't get removed....... unless the latest version was installed over the broken version. Then, because those files are in the uninstall log without that flag, they get removed upon uninstall!
I can't ask my users to uninstall the old software before upgrading, because then they would lose those files.
Can I force Inno Setup to regenerate the uninstall log from scratch? Or at least remove/overwrite the entries for these files? I want the uninsneveruninstall flag to be retroactive.
You can't change that flag retroactively. Once it's been released, then that's it.
An option though would be, during the setup, to detect the older broken version having been installed (If not by version number, maybe a flag in the registry to say the fix has been applied) and backup the folder in question, perform an uninstall (silently) then restore the folder.
The setup can then carry on as normal.

Resources