Composer repacking

[markc0]

Hello, i have a pkg (not made by me), when i convert this to source in composer and then make the slight change like place a space into one of the two scripts that the pkg consists of and then save
This makes the pkg (which is fine) but when i run the pkg installer it fails.
The package consists of just two scripts

what is composer doing to the pkg when it saves it?
thanks

[JPDyson]

Space magic. Composer is doing space magic.

In all seriousness, can we have a look at the modified script?

[markc0]

Hi its not the modification of the script its the re-saving it after its been converted from source.
for example #!/bin/bash
#this is a script bla bla bla

if i change this to
#!/bin/bash
#this is a scripts
bla bla bla

now that i ahve made the chnage i save this and select build as pkg, run the installer and it fails.
if i convert the pkg then make no chnages to the script and then build as pkg , run the installer its fine.
The orignal pkg is OracleJava8-1.8.25.17

Thanks

[mm2270]

Without even seeing it, I suspect the space you're adding to the script is causing some or all of the script to fail. You have to be careful with bash scripts and spaces. They are seen as delimiters, so if you're adding a space into something that should be considered a single string or variable, it will run into problems.
I agree with @JPDyson, post the modified script please and someone will likely be able to tell you where its going wrong.

The other possibility is that the conversion from the original package into a Composer source didn't pull everything in. Was the original pkg made in Composer or is it a commercially made package? I've had hot and miss luck with getting conversions to work, especially with some commercially developed pkgs. Most times they do, but certain ones simply don't get converted correctly or may be missing something the script is expecting to see, which could be the cause of the failure.

[mm2270]

@markc0 - silly question, but what version of Composer are you using for this? There was a bug a few versions back that could cause scripts to recompile with things like curly quotes instead of straight quotes as an example. I don't know if that's what's happening, but just wondering what version you are on.

[markc0]

its 9.61

[mm2270]

Yeah, pretty sure that was the version with this bug in it. See this thread here:
https://jamfnation.jamfsoftware.com/discussion.html?id=12644

Just an FYI, you can use any version of Composer you want along with your JSS 9.61 instance (I assume that's what you're running) Just go up to your JN account and under My Assets, download the latest release and grab Composer from it. Its a standalone app and won't care if you use a newer/older version than your JSS since it doesn't connect to it like Casper Admin, etc.
Beyond that, any particular reason you are still on 9.61?

[markc0]

I have just updated to 9.65 and now im seeing convert the pkg to Source and then build as pkg (making no chnages) run the installer then it fails

[mm2270]

Updated Composer to 9.65?
If so, then it sounds like something else is going on. The conversion may be part of the cause here. Not sure. Again, was the pkg built by someone originally in Composer or is it commercially built?

[markc0]

yes composer 9.65
Commerically built pkg

[brandonusher]

Have you made sure permissions are correct on the script? If you have other scripts in there, try looking at those permissions and copying them onto that script.

[mm2270]

If its commercially built, its remotely possible the package installer is doing a checksum on the components. Any change to a script or other part of a package will change its checksum, even simply adding a space or another character. Its kind of a shot in the dark, but it could be doing that, which would cause it to fail after the modifications.

You may be able to see exactly why its failing by doing the install from the command line and using a verbose flag.

sudo installer -pkg /path/to/recompiled/OracleJava8-1.8.25.17.pkg -tgt / -verbose

It may actually report what's causing the failure when done this way. Worth a try.
Checking permissions on the script after modifying it is also a good idea.

[markc0]

Ok got, convert to source was not converting and showing all the files.
I have used pkgutil with --expand and --flatten to make my modifications to the pkg

[mm2270]

We probably should have backed up two steps here, but what is the reasoning behind needing to modify the package? I generally advise and feel commercially supplied packages shouldn't be modified. As tempting as it may be, there is sometimes a method to the madness in those packages (and sometimes its just pure madness)
I'd be willing to bet that whatever the reason behind needing to change the pkg can be done outside of it in some other way, but since you didn't mention your need with this, its hard to say.

[RobertHammen]

Agree completely with @mm2270. I've not used Composer to modify commercial packages - generally those are signed and, as he pointed out earlier, there may be some other kind of checksum.

I understand the need to sometimes edit packages (i.e. Office 2011 updaters and removing the all_quit function), but I think the path you went down (pkgutil --expand and pkgutil --flatten) is probably the best approach if you absolutely need to.

Otherwise, there are Installer choices XML files that can be used to customize existing Installer pkg files without modifying them...