Repackaging software for self-service

[anickless]

I am wondering how others prep software for installation via self-service.

My workflow is to use the packages.app and then dump the .dmg of what I want people to install onto it and then build a .pkg that I upload to casper admin. It works for a lot of applications but I have trouble with the odd one here or there (Tracker: a visual physics rendering program) so I am always wanting to learn other ways to do the same thing.

[CapU]

I use composer primarily. I then look at the package and change the permissions to make sure Standard users can either save to a folder Ive created or the default location then create a .pkg or .dmg. Some apps don't need fiddling with, I just have to upload the .pkg thru Casper Admin.

[blackholemac]

This topic can start debates for sure.

I use a mix of Pre-vetted .pkgs from vendors or ones I've hand built for very simple ones (like a user drag n drop package). Sometimes a pre-built one plus a correction script works, sometimes. Other times I build my own using my favorite tool of the day.

For OS packages I use Autodmg since imaging does play a role in our org.

Other times I'll use Composer. I do have a standing rule to avoid snapshot packages in Composer.

That being said, there are quite a few on here that rule that out for very good reason. I won't rule that entirely out as I sometimes have some pretty gnarly vendor installers that are beyond hope.

I also use Composer as a learning tool to see what gets installed or modified when I want to see what a vendor package actually does to a Mac in a given state.

Be wary of snapshot packages unless you can't do what you want any other way.

If forced to use a snapshot package, I tend to put that app under much more rigorous testing to make sure that every obscure feature in the app works.

In general about 95% of my packages are vendor ones or ones I've made using a packaging tool. I only have about five that were truly done with snapshots only (out of about 200). 3 of those were InstallerVISE or BitRock installers.

Composer plays a role for us and does well at what it does, but I don't want high maintenance installers when I don't have to .

Your package sounds like a good candidate for Composer snapshots in study mode not necessarily as a final snapshot package. What I might do is capture the file system, run the stock installer...capture the file system again, keep the output from that for testing but not for deployment but to help me understand.

Finally, when it's all done Installing the base installer, I might run Composer again in "new and modified" mode then I would hand the package building MacBook to my best user of that particular software and have him/her do their worst...I would also do my worst looking for updates, content modules, etc...once done I would tell Composer to capture the changes and see what it outputs...I would learn whether the program is downloading further .pkg installers or XML from somewhere...maybe it's just massaging permissions, maybe it is populating things in the user home folder. This is a perfect example of me using Composer to know what I'm up against in graphical form.

For packages that install stuff to the active user home folder, I typically hand build a "support software package" that lays on that type of content (making use of Casper Admin's ability to fill the home folders and user templates on a machine).

In short I'll use any tool or log file I have to understand my package, but my final product should ideally not come from a snapshot. It goes without saying...always test your final product...you don't want a user coming back and saying 'I need a serial number' or 'I need admin rights' when they launch for the first time.

[tdclark]

First off I apologize for hijacking the thread a bit, but I have a followup for @blackholemac . I just came across an app that uses a BitRock installer. I've tried doing what you suggest in the 2nd to last paragraph of building a DMG and filling home folders with the drilled in XML file. Is this the only solution you've come across? This particular program drops an XML file into the ~/library/application support/*appname folder which contains the server to connect to. Building just that part as a DMG that installs after the rest of the information was my solution, but I'd love to hear other solutions. I've complained to the developer several times to no avail.
Thanks!

[blackholemac]

Being that packaging is my true favorite topic, I'd love to help take a whack at it...the short of it is that some software is just abject poop in an enterprise world...I have two bitrock packages I've made work...feel free to reach out if you like. Sorry my advice didn't work.