Composer 8.52 bug

[tkimpton]

Hi guys

I like to carry out version control in Composers source pane. For example if i drag Composer in the Source i will rename it immediately to some thing like Composer_8.52_v1.0

Unfortunately if you do this and build the pkg, it will fail silently.

I have a preinstall bashcript to simply delete the previous version eg rm -rf /Applications/Composer.app

What actually happens is that preinstall (or preflight) script runs, but the new item doesn't get installed at all.

The current work around is to not rename the source item within Composer and instead rename it after you have built the pkg like Get Info and changing the name there.

Hope this helps people out. This has been driving me nuts for about 4 hours!

[jarednichols]

Have you tried doing your re-name, and then quitting and re-launching Composer?

[tkimpton]

Please note i have been working on this for 4+ hours (BST) ..... No that doesn't make any difference :(

[jarednichols]

Well I ran into a very similar issue where if I renamed the package, the contents of it would "disappear." That's why I asked. Re-launching after renaming solved it. It was like Composer hadn't picked up the name change of the source's folder structure in Composer's working folder.

[talkingmoose]

I've seen the disappearing behavior as well under 8.43. Restarting Composer makes files appear again.

[Matt]

Having the dragging files and not seeing them until I reopen Composer issues. 8.53 :D

[tkimpton · Accepted solution]

An Answer

"Thanks very much for the detailed information here. We have now replicated this here and created a defect for this issue. The defect can be detailed with ID - D-002856"

[talkingmoose]

Thanks for reporting this, Tim! I hadn't pursued my own testing to know if I was the only one seeing this issue or others were seeing too. So nice to have dialog with others.

[#9]

I've noticed this with several otherwise simple drag-n-drop kinds of package builds (Chrome, Dropbox, etc). Renaming the package, then quitting Composer, reopening Composer, and *then* building the package (I've only been trying .dmg) seems to create a working package.

Good catch on the naming bug though. Things like Firefox and Chrome and now being updated so often that I find naming the packages with the version number to be a lot easier than just constantly rebuilding and reuploading something generic ("Firefox.dmg").

Would love to see Composer/Admin get a little smarter about handling version numbers..

[jarednichols]

It's not an issue of Composer being smarter. Renaming the source used to be fine as I've always put in the version number as a matter of course. It's a bug introduced in 8.43 I believe.

[tkimpton]

Unfortunately i think you guys are referring to a bug i ahave never ever ever ever experienced with Composer in 6 years of using it. And it is not the bug i am talking about or refering to.

I rename sources right now in Composer 8.51 no problem!

Version control is essential. Scenario my CS5 pkgs started at version 1.0.

Im on version 3.9

Adobe_CS5_Standard_UK_v3.9

Often i had to keep the last 2 versions just incase something went wrong

This is the problem in detail i experienced and logged to support to get the bug defect id

Replicating the issue with version control naming in Composer 8.52 sources pane

1. Download Firefox 12

2. Copy Firefox 12 from the downloaded and mounted dmg

3.Open. Composer and authenticate as an admin user

1. Drag Firefox to the sources pane in Composer.

2. You should now have Firefox in as a source in Composer.

3. RENAME Firefox to Firefox_12.0_v1.0

4. Change permission on the Firefox_12.0_v1.0 source if appropriate (I always chown -R root:admin chmod -R 775)

5. Add a preinstall bash script with the following

# Kill Firefox
killall firefox

# Delete the App
rm -rf /Applications/Firefox.app/

# Sleep 10

1. Then save the added preinstall bash script and make sure it compiles correctly

2. Build the package to your desktop (or a relevant test machine)

3. Install the newly created Firefox_12.0_v1.0 to pkg to your machine.

4. You will see whilst the installation is in progress the preinstall script runs and the current Firefox gets deleted ....BUT...the version within the pkg is not installed!

Workaround

1. Is to delete the source and start again ... BUT this time skip step 6 and build the pkg so it is called Firefox.pkg to the desktop.

2. Once it is built to you desktop then and only then RENAME through the Finder or Get info Firefox.pkg to Firefox_12.0_v1.0.pkg

3. Installing Firefox_12.0_v1.0.pkg now works exactly as expected.

Conclusion

1. Composer 8.51 and below works fine carrying out version control naming within the sources pane

2. The implementation of a fix for Final Cut Studio manifest (see release notes for CasperSuite8.52) must have broken something because this is the only change.

3. I am rolling back and using Composer 8.51 because it works and I can't work with this bug in Composer 8.52 because I will make mistakes in version control naming.

[davidhiggs]

Hey guys,

I've been struggling with this issue, I didn't know it was Composer 8.52 at fault until I started to backtrack my steps. My issues are slightly different but definitely related to the same bug.

Thought I would mention some things I discovered when diagnosing the issue:

- Renaming the source then building will result in a bad package in Composer 8.52, DMG or PKG. Doesn't happen in 8.51.
- Renaming the source, quitting Composer 8.52, re-opening Composer 8.52 THEN building will result in a good package, DMG or PKG (workaround)
- Composer 8.51 is probably safer to work with atm, the rest of the 8.52 tools seem to be OK

I've mainly been working with DMG packages this past week. The bug is creating a DMG that has included the top level of the Composer folder structure, ie. ROOT, Scripts, Settings, Snapshots. This incorrect folder structure is then copied to the target machine's root directory.

[tkimpton]

Hi David

I noticed that as well just recently but couldn't reproduce. Please report this to JAMF support.