I have an installer script for my product, let's say, project.xml. This installer works for 3 platforms that we need: windows, linux, osx. We generate <linux-install>.run, <win-install>.exe and <mac-install>.app. Also, there is a selection at runtime, whether we need to pull in 32-bit libs or 64-bit libs for our product depending on the underlying OS.
Now, we are asked to add linux natives <linux-install>.rpm, and <linux-install.deb>.
Inside the main script, project.xml, I have logic that differentiates between 32 bit and 64 bit underlying OS, and selects libs components, accordingly. For example, to generate <linux-install>.run, if we detect linux-32, we will select "linuxfiles32" component; similar, for 64-bit. This logic on checking underlying OS, and doing "componnetSelection" lives under "preInstallationActionList" entry.
Now, according to BitRock's answers to RPM and DEB generation, this step is NOT executed for RPM and DEB.
My initial solution was to create two separate installer scripts for RPM/DEB, one for each bit-ness (32 and 64). Then we would generate "pre-canned" installers for our users, without determining OS bit-ness at runtime.
But I wonder if there is a way to still stay with original project.xml and be able to know which components to pull based on underlying OS-bitness, if we are doing RPM or DEB? If so, where within the script should I do "componentselection" provided that " preInstallationActionList" is not executed for DEB/RPM?
asked 10 Sep '12, 21:39
The RPM and DEB archive creation does not use most of the logic and it is not possible to enable/disable certain components based on actions and rules when generating native packages.
The reason is that native packaging systems are deploying the files, not InstallBuilder itself. While the actions are run, some things such as modifying files to run or actions such as
For the scenario described above, we recommend creating two different projects - one for 32bit and one for 64bit.
answered 11 Sep '12, 06:03