The previous SoftwareUpdates are not stored, only records about them. Storing them would just waste space. So if you use SoftwareUpdate to pull down the updates, they are gone once you apply them. While they are waiting to be installed they wait in /Library/Updates.
The previous SoftwareUpdates are not stored, only records about them. Storing them would just waste space. So if you use SoftwareUpdate to pull down the updates, they are gone once you apply them. While they are waiting to be installed they wait in /Library/Updates.
Any software that has a pkg also has a Bill Of Materials file. This is simply a list of individual files that the pkg needed to install itself so that if you need to uninstall the software it's very easy
As an FYI if you didn't know already... if a piece a software was installed from a pkg then it should also have an uninstall.pkg and you should use it.
Any software that has a pkg also has a Bill Of Materials file. This is simply a list of individual files that the pkg needed to install itself so that if you need to uninstall the software it's very easy
With the new flat-file format BOMs are no longer stored in /Library/Receipts. Instead the same basic information is stored in a new database in /Library/Receipts/db. But even this list of files is still dangerous to use as a hit-list to remove things for a few of reasons:
- it can be difficult to know when multiple programs all depend on the same files
- scripts can modify important files, and none of the systems necessarily catch that (things like /etc/authorization can be nasty if they get out of sync)
- it is hard to know how to reverse changes to files (think preference files)
The whole uninstalling things is a really nasty problem, and every solution I have seen for it (on any platform) has major problems with it.
Quote:
As an FYI if you didn't know already... if a piece a software was installed from a pkg then it should also have an uninstall.pkg and you should use it.
I don't know where you have seen uninstall.pkg's, but they are relatively rare, and difficult to do without making dangerous assumptions. The new database for the flat-file format is a step in trying to make this solvable later, but my personal opinion is that it is a step in the wrong direction there.
Comments
Where does OS X Software Update keep the .pkg files that I've downloaded previously?
It would be a real timesaver if I could simply drag a downloaded .pkg file to another computer rather than waiting on it to download again!
In your Mac HD/Library/Receipts folder
Also, the Office 2008 files that are there are only a few hundred KB in size ? but the originals were several hundred MB in size.
The previous SoftwareUpdates are not stored, only records about them. Storing them would just waste space. So if you use SoftwareUpdate to pull down the updates, they are gone once you apply them. While they are waiting to be installed they wait in /Library/Updates.
Ah!
Nice one, thanks for that!
Any software that has a pkg also has a Bill Of Materials file. This is simply a list of individual files that the pkg needed to install itself so that if you need to uninstall the software it's very easy
As an FYI if you didn't know already... if a piece a software was installed from a pkg then it should also have an uninstall.pkg and you should use it.
Any software that has a pkg also has a Bill Of Materials file. This is simply a list of individual files that the pkg needed to install itself so that if you need to uninstall the software it's very easy
With the new flat-file format BOMs are no longer stored in /Library/Receipts. Instead the same basic information is stored in a new database in /Library/Receipts/db. But even this list of files is still dangerous to use as a hit-list to remove things for a few of reasons:
- it can be difficult to know when multiple programs all depend on the same files
- scripts can modify important files, and none of the systems necessarily catch that (things like /etc/authorization can be nasty if they get out of sync)
- it is hard to know how to reverse changes to files (think preference files)
The whole uninstalling things is a really nasty problem, and every solution I have seen for it (on any platform) has major problems with it.
As an FYI if you didn't know already... if a piece a software was installed from a pkg then it should also have an uninstall.pkg and you should use it.
I don't know where you have seen uninstall.pkg's, but they are relatively rare, and difficult to do without making dangerous assumptions. The new database for the flat-file format is a step in trying to make this solvable later, but my personal opinion is that it is a step in the wrong direction there.