Prompted for any previously-downloaded updates when used for AppleUpdates only

[GoogleCodeExporter]

What steps will reproduce the problem?
1. deploy workstation with apple's auto-checking for software updates on 
(default)
2. revisit workstation after updates are auto-downloaded
3. install munkitools with AppleSoftwareUpdatesOnly and 
InstallAppleSoftwareUpdates set to true
4. run Managed Software Update.app

What is the expected output? 
The same output as softwareupdate -l

What do you see instead?
The pre-existing updates, and any applicable delta updates instead of combo's

What version of the product are you using? On what operating system?
munkitools-0.7.0.1004.0.pkg on 10.6.4 client

Please provide any additional information below.
Resolved by deleting unnecessary updates zzz123-4567 folders from 
/Library/Updates
Please pardon me if this has been reported elsewhere

Original issue reported on code.google.com by allister...@gtempaccount.com on 9 Feb 2011 at 2:09

[GoogleCodeExporter]

Since munki uses Apple's mechanisms to download Apple updates, this is 
unavoidable unless we delete all downloaded updates every run and re-download 
them, which is terribly inefficient. Admins transitioning to munki will need to 
be aware of this and plan accordingly.

Original comment by gregnea...@mac.com on 9 Feb 2011 at 2:24

[GoogleCodeExporter]

this bug allready made two of our clients unusable by installing a 10.6.4 over 
an 10.6.6 

Original comment by he.kess...@googlemail.com on 10 Feb 2011 at 12:33

[GoogleCodeExporter]

How is that even possible?

Original comment by gregnea...@mac.com on 10 Feb 2011 at 1:44

[GoogleCodeExporter]

is it really that way? what happens if you uncheck automatic downloading in 
Apple SoftwareUpdate Preferences, then delete everything inside of 
/Library/Updates. after this procedure the only process which would fillup this 
directory would be munki itself and you only would get into trouble if someone 
refuses to update for a long period. or am i wrong?

Original comment by he.kess...@googlemail.com on 10 Feb 2011 at 6:52

[GoogleCodeExporter]

"what happens if you uncheck automatic downloading in Apple SoftwareUpdate 
Preferences, then delete everything inside of /Library/Updates. after this 
procedure the only process which would fillup this directory would be munki 
itself"

An admin user can run Software Update manually as well, which would populate 
this directory.

Original comment by gregnea...@mac.com on 10 Feb 2011 at 7:32

[GoogleCodeExporter]

Allister, are you missing some steps from the steps to reproduce?

Are you between 2 & 4:
- pointing apple software update / munki to a different software update 
server/sucatalog?
- installing some of the apple software updates by some other mechanism (making 
them no longer necessary)?
- changing some flag that should favour combos over patch?

Perhaps I'm not understanding something in your setup. The auto-downloaded 
updates should be the ones Apple thinks your computer needs. Why would apple 
software update think your computer needs different updates after installing 
munki? Something else appears to have changed that invalidates this logic at 
your site.

Original comment by rrmiddleton@gmail.com on 12 Feb 2011 at 4:17

[GoogleCodeExporter]

Hey Mr. Middleton,
Between 2 and 4 I performed none of the above, apple's SUS, no installs, no 
flags(although I'm intrigued - do flags to prefer combo's instead of delta's 
exist?).  The auto-downloaded ones are deltas accrued over time, and apple 
apparently did not reap existing updates from that folder in both situations I 
observed at the same environment.
Man, it would be cool to select combo updates instead, we would need to take 
into account that that would invalidate the need for certain packages(e.g.: 
safari 5.0.2 being rolled into 10.6.5 if I recall correctly), which would add a 
step/reboot when not using a munki server.

Also, I wanted to point out that I do consider this a defect that harms 
bootstrapping in a viable usage of the product, since it is humanly possible to 
install 'sub-optimal' packages when starting deployment, but should still be a 
lower-priority issue to the project.  
Now if I could get 'softwareupdate --schedule off' to work on the first try, it 
doesn't work until you toggle it once in the GUI; the CLI doesn't seem to 
initialize the ByHost scheduler pref properly.  Funny too, that the only thing 
that pref does when you turn the schedule off is set the next date to check to 
be Dec 31st, the year 4000 at 7PM - somebody's idea of a joke at Apple.

Original comment by allister...@gtempaccount.com on 12 Feb 2011 at 4:36

[GoogleCodeExporter]

This should be addressed with the new Apple update code merged to trunk in 
r1259.

Original comment by gregnea...@mac.com on 2 Aug 2011 at 4:18

• Changed state: Fixed