Munkiimport automatically add blocking_applications

[GoogleCodeExporter]

Would it be possible to have munkiimport auotmatically generate the pkgsinfo 
files with a default blocking_applications key that is set to at minimum block 
the *.app that is being passed to munkiimport.  So everytime you use 
munkiimport for things like Firefox it will automatically add something like...

        <key>blocking_applications</key>
        <array>
                <string>Firefox.app</string>
        </array>

Also possibly do this with using munkiimport on .pkg and .mpkg files by 
searching the list of programs to be installed and finding the *.app items.

I could possibly try the addition myself if anyone could direct me to the place 
in munkiimport that might be best to implement this.  I'm not very experienced 
with python but definitely willing to learn.

Thanks
- Trey

Original issue reported on code.google.com by treyd...@gmail.com on 22 Apr 2011 at 2:58

[GoogleCodeExporter]

For copy_from_dmg installers, munki already gives you the behavior you want. If 
there is no blocking_applications list, and there _is_ an installs list, munki 
uses any applications listed in the installs list as implicit blocking 
applications.  So when using munkiimport to import a new diskimage containing 
Firefox.app, munki will consider Firefox as an implicit blocking_application.

For package installs, this would be a useful enhancement. munki could look 
through the payload and add any applications found to a blocking applications 
list. Some care would need to be taken to try to avoid adding applications that 
the user does not interact with (faceless background apps, for example).

Original comment by gregnea...@mac.com on 22 Apr 2011 at 3:20

• Changed state: Accepted

[GoogleCodeExporter]

I did a little proof-of-concept code, and it found the following applications 
in the installer metapackage for Office 2011:

Microsoft Database Utility.app
Microsoft Outlook.app
Microsoft Upload Center.app
Microsoft Excel.app
Microsoft Chart Converter.app
Microsoft Office Setup Assistant.app
Alerts Daemon.app
Microsoft Communicator.app
Microsoft Database Daemon.app
Microsoft Ship Asserts.app
Microsoft AutoUpdate.app
Microsoft Document Connection.app
Open XML for Excel.app
Microsoft PowerPoint.app
Microsoft Clip Gallery.app
Microsoft Graph.app
Equation Editor.app
Microsoft Office Reminders.app
Microsoft Messenger Daemon.app
Microsoft AU Daemon.app
Microsoft Messenger.app
Microsoft Language Register.app
Microsoft Error Reporting.app
Microsoft Word.app
Remote Desktop Connection.app
My Day.app
SyncServicesAgent.app

So we'd need to be a little more intelligent about filtering the list...

Original comment by gregnea...@mac.com on 22 Apr 2011 at 11:34

[GoogleCodeExporter]

Would it be possible to filter apps that are going to be located in 
/Applications?  A problem I can imagine with that filter assumption is many of 
the apps in that list are called by the primary apps in /Applications.

Assuming the package making (Microsoft, or worse Adobe) is using the correct 
standards could munkiimport find which applications the installer will check to 
see if they are open before installing?  So assuming the Office metapackages 
will not install if Word.app is open, could munkiimport find that out based on 
what's in the metapackage?  Is there something in standard metapackages that 
does that kind of check or do packagers have to put that in a preflight script? 
 If it's a preflight script then this idea could be a bit of a challenge.

- Trey

Original comment by treyd...@gmail.com on 23 Apr 2011 at 11:13

[GoogleCodeExporter]

"Would it be possible to filter apps that are going to be located in 
/Applications?"

I assume you mean could the list be filtered to include only apps that will be 
located in /Applications or a subfolder thereof. That would be a useful "first 
approximation", but might need further refinement.

"Assuming the package making (Microsoft, or worse Adobe) is using the correct 
standards"

That leaves most Adobe products out since they don't have standard Apple 
packages.

"could munkiimport find which applications the installer will check to see if 
they are open before installing?"

Not without parsing preflight scripts, or in the case of the Adobe CSx stuff, 
parsing their installer code.

"So assuming the Office metapackages will not install if Word.app is open, 
could munkiimport find that out based on what's in the metapackage?"

No; at least not in a generic fashion applicable to all/most packages.

"Is there something in standard metapackages that does that kind of check or do 
packagers have to put that in a preflight script?"

Preflight script.

"If it's a preflight script then this idea could be a bit of a challenge."

Yes.

Original comment by gregnea...@mac.com on 23 Apr 2011 at 11:39

[GoogleCodeExporter]

I am not sure the blocking_applications is being added correctly by 
munkiimport.  I've tested now both Skype and Chrome using munkiimport and that 
key is never added automatically.  Both times I've imported the .dmg file and 
then tried the actual .app and same results both times.

What is the preferred method for importing simple .app programs with 
munkiimport, doing it by importing the dmg or the app itself?

Was the blocking_applications in munkiimport added in a revision later than 
r1097?  That's what I'm running on the majority of my systems.

Thanks
- Trey

Original comment by treyd...@gmail.com on 29 Apr 2011 at 2:01

[GoogleCodeExporter]

There have been no changes committed to munkiimport for this issue; munkiimport 
does not currently automatically add blocking_applications to pkginfo files.  
As explained earlier, that does not matter for drag-n-drop diskimages; the 
application in the installs key acts as an implicit blocking application.

"What is the preferred method for importing simple .app programs with 
munkiimport, doing it by importing the dmg or the app itself?"

Either should produce the desired results. When importing an app bundle, the 
first step is to create a diskimage and copy the app into it, so if you already 
have a diskimage with the app, using that is more efficient.

"Was the blocking_applications in munkiimport added in a revision later than 
r1097?"

No, munkiimport has never added blocking_applications. That remains a manual 
task for the munki admin.

Original comment by gregnea...@mac.com on 29 Apr 2011 at 3:24

[GoogleCodeExporter]

This can probably be marked as closed.  Since now I can create the necessary 
pkgsinfo file using features from r1164 manually once for a new application.  
And now that munkiimport keeps the blocking_applications key that was in r1155. 
 That workflow will do exactly what I need.  Thanks Greg and other devs!

- Trey

Original comment by treyd...@gmail.com on 6 May 2011 at 2:33

[GoogleCodeExporter]

Marking this old issue as closed.

Original comment by gregnea...@mac.com on 1 Nov 2011 at 4:48

• Changed state: Done
• Added labels: Type-Other
• Removed labels: Type-Enhancement