Mac-apps verwijderen die met een .pkg-pakket zijn geïnstalleerd

Een app die als .pkg-installatieprogramma binnenkwam, is niet hetzelfde als een app die je uit een schijfimage hebt gesleept. Het installatieprogramma draaide als root, het kon schrijven waar het pakket dat zei, en het liet een verslag achter van wat het installeerde in de database met installatiebewijzen van Installatieprogramma. De app naar de prullenmand slepen verwijdert een van de mappen die dat verslag noemt en laat de rest staan, inclusief het verslag zelf. Dit artikel gaat over dat geval: hoe je ziet dat een pakket de app heeft geïnstalleerd, hoe je leest wat het op schijf heeft gezet, wat je verwijdert en wat je laat staan. Weigert de Finder het ronduit, of komt de app terug nadat je die hebt verwijderd, begin dan met als een Mac-app niet wil verdwijnen, en voor een app die je zelf hebt binnengesleept behandelt de volledige verwijdergids het gebruikelijke pad.

Waarom de prullenmand niet genoeg is

Een pakket kan bestanden naast de app zetten, niet alleen erin. Toen ik een reeks apps opnieuw installeerde vanuit hun officiële installatieprogramma's en ze daarna weer verwijderde, liet het officiële Zoom-pakket drie launchd-taken en een geprivilegieerde helper achter, us.zoom.ZoomDaemon, buiten zoom.us.app. Het installatieprogramma van Logi Options+ installeerde ook een tweede product, LogiRightSight, met een eigen installatiebewijs en een eigen launch agent. DisplayLink Manager voegde een launch agent toe aan /Library/LaunchAgents. Microsoft Office installeert een gedeeld frameworks-pakket dat Word, Excel en PowerPoint allemaal laden, en Microsoft AutoUpdate plus een licentiehelper komen mee. Geen daarvan beweegt als de app-bundel dat doet.

Het installatiebewijs beweegt ook niet. Het staat in de eigen database van Installatieprogramma, los van de bestanden die het beschrijft, dus de app verwijderen laat pkgutil het pakket nog als geïnstalleerd melden. Na een schone run van het officiële verwijderprogramma van DisplayLink stonden de twee installatiebewijzen er nog.

Een wachtwoordvraag in de Finder is het andere teken dat je met een pakket te maken hebt. Het installatieprogramma draaide als root, dus de bundel die het achterliet is eigendom van root, en verplaatsen vraagt authenticatie. Dat is normaal en staat in de gids voor problemen bij verwijderen.

Controleer of een pakket het heeft geïnstalleerd

Begin met de lijst installatiebewijzen en het eigen pad van de app:

pkgutil --pkgs | grep -i zoom
pkgutil --file-info /Applications/zoom.us.app

pkgutil --pkgs toont elke pakket-ID die Installatieprogramma op het opstartvolume heeft vastgelegd. Zoek op de leverancier en de productnaam, niet alleen op de bundle-identifier van de app, want die twee hebben vaak niets gemeen. De app van Zoom is us.zoom.xos en het installatiebewijs is us.zoom.pkg.videomeeting. Het installatiebewijs dat Cookie.app installeert, is app.fantasticthing.Bookkeeping. Zelfs het hoofdlettergebruik kan verschillen: de bundle-identifier van 爱思助手 is cn.i4Tools.mac en het installatiebewijs is cn.i4tools.mac, en pkgutil vergelijkt ID's exact, dus de spelling met gemengde hoofdletters antwoordt "No receipt" terwijl het installatiebewijs er gewoon staat. Kopieer de ID uit de uitvoer van --pkgs in plaats van die te typen.

pkgutil --file-info hoort het pakket te noemen dat een pad heeft geïnstalleerd, in regels pkgid: onder het pad. Lees een ontbrekend antwoord niet als "niet uit een pakket". Op macOS 27 drukte het voor de meeste paden alleen volume en path af, verwijderd of aanwezig; de app van DisplayLink Manager kreeg dat lege antwoord terwijl de twee installatiebewijzen nog op de Mac stonden. Een installatiebewijs is ook geen bewijs dat je zelf een .pkg hebt gedraaid: de Mac App Store laat er een achter voor sommige apps, zoals com.apple.pkg.TestFlight.

Wat een installatiebewijs vastlegt

Twee opdrachten tonen wat één pakket heeft geïnstalleerd en waar:

pkgutil --pkg-info us.zoom.pkg.videomeeting
pkgutil --files us.zoom.pkg.videomeeting

--pkg-info toont de pakket-ID, de versie, volume, location en het installatietijdstip. --files toont paden relatief ten opzichte van dat volume en die locatie, dus het echte pad is de drie aan elkaar. Een installatiebewijs met locatie Applications toont Foo.app/Contents/...; een met een lege locatie toont in plaats daarvan Applications/Foo.app/.... Lees de locatie voordat je de lijst leest, anders is elk pad dat je opzoekt fout.

De lijst bevat mappen én bestanden. --only-files en --only-dirs splitsen de twee, wat nuttig is zodra je ziet dat een installatiebewijs Library en Library/LaunchAgents zelf kan noemen. De ruwe verslagen staan in /private/var/db/receipts als een .bom en een .plist per pakket, maar de handleiding van pkgutil zegt dat de locatie van bewijsbestanden kan veranderen en dat je ze altijd via pkgutil moet opvragen.

Een installatiebewijs is een kaart, geen verwijderlijst

Het is verleidelijk om pkgutil --files in een lus te stoppen en alles te verwijderen. Zo breekt een pakketverwijdering iets anders. De lijst zegt wat dit pakket schreef, niet wat alleen dit pakket gebruikt:

De lijst mist ook dingen. Hij legt vast wat de payload van het pakket op schijf zette. Scripts van Installatieprogramma kunnen meer doen, en pakketten dragen die: die van Foxit heeft bijvoorbeeld een postinstall-script en een updatedienst. De app schrijft eigen gegevens onder je thuis-Library zodra die draait, en niets daarvan staat in een installatiebewijs. Gebruik voor die kant restbestanden vinden na een verwijdering.

Draai eerst het verwijderprogramma van de leverancier

De aanwijzing van Apple over apps verwijderen is hier direct over: bevat een app een verwijderprogramma, dan is "dat de beste manier om de app te verwijderen en eventuele inlogonderdelen, extensies of andere gegevens die de app op andere locaties kan hebben opgeslagen." Software die via een pakket is geïnstalleerd, levert er vaak een, omdat de leverancier de eigen scripts, helpers en gedeelde delen kent. Kijk in de schijfimage waar het pakket in zat, in de map van de app in Programma's, in /Applications/Utilities, in de eigen menu's van de app, en op de ondersteuningssite van de leverancier. Splashtop Personal zet het verwijderprogramma bijvoorbeeld in dezelfde schijfimage als het pakket.

Heb je de app al naar de prullenmand gesleept, zet die dan terug met Bestand › Zet terug, open die, en draai het verwijderprogramma van daaruit. Voor beveiligingssoftware, VPN-clients en drivers is de tool van de leverancier niet optioneel: extensies en netwerkfilters komen alleen naar beneden via de app die ze bezit, wat antivirus verwijderen op de Mac behandelt.

Met de hand verwijderen

Is er geen verwijderprogramma, dan zegt het installatiebewijs waar je kijkt. Werk er in deze volgorde vanaf:

1. Sluit de app af en alles wat die op de achtergrond draait.
2. Lees --pkg-info voor de locatie, daarna --files voor de lijst, en schrijf de paden buiten de app-bundel op.
3. Laad voor elke launch agent of daemon in de lijst de taak uit met launchctl bootout voordat je de plist verplaatst. Het launchd-deel van de gids voor problemen legt uit waarom de volgorde telt.
4. Verplaats naar de prullenmand alleen wat duidelijk bij dit product hoort: de app-bundel, mappen en plists genoemd naar de bundle-identifier of het product, de helper in /Library/PrivilegedHelperTools. Laat gedeelde bovenliggende mappen staan en alles wat andere apps van de leverancier nog gebruiken. pkgutil --pkgs | grep -i vendorname toont of er nog andere pakketten van dezelfde leverancier geïnstalleerd zijn; zo ja, dan blijven hun gedeelde frameworks staan.
5. Schrijf het installatiebewijs als laatste uit de catalogus, zodra niets dat het noemt nog over is:

sudo pkgutil --forget com.vendor.pkg

--forget gooit het installatiebewijs weg en, in de woorden van de handleiding, "raakt de geïnstalleerde bestanden niet aan". Het eerst draaien laat elk bestand staan zonder een verslag dat ernaar wijst, wat de rest van deze taak moeilijker maakt. Het heeft sudo nodig omdat /private/var/db/receipts eigendom is van root, en het heeft de ID nodig precies zoals --pkgs die spelt. Een verouderd installatiebewijs bevat geen gebruikersgegevens, dus als je niet zeker weet of iets dat het noemt nog in gebruik is, kost het bewijs laten staan niets.

Het resultaat controleren

Deze opdrachten lezen alleen. Vervang com.vendor.pkg en vendorname door wat je hierboven hebt gevonden:

id=com.vendor.pkg
loc=$(pkgutil --pkg-info "$id" | sed -n 's/^location: //p')
pkgutil --files "$id" --only-files | while IFS= read -r f; do
  p="/${loc:+$loc/}$f"
  [ -e "$p" ] && echo "$p"
done
pkgutil --pkgs | grep -i vendorname
ls /Library/LaunchAgents /Library/LaunchDaemons /Library/PrivilegedHelperTools | grep -i vendorname
launchctl list | grep -i vendorname
launchctl print system | grep -i vendorname

De lus toont elk bestand uit het installatiebewijs dat nog bestaat, met het volledige pad. Geen uitvoer betekent dat de payload weg is en het installatiebewijs veilig uit de catalogus kan. Uitvoer binnen de app-bundel betekent dat de app nog geïnstalleerd is; uitvoer elders is wat de verwijdering heeft gemist, of wat je hebt besloten te bewaren omdat een andere app het deelt. Antwoordt pkgutil "No receipt for ... found", dan is het installatiebewijs al uit de catalogus of is de ID anders gespeld. De regels ls en launchctl vangen helpers die het installatiebewijs nooit noemde. launchctl list toont je eigen agents en launchctl print system toont de daemons. Elke regel van een van beide betekent dat de taak nog geladen is, en een getal anders dan nul in de eerste kolom betekent dat die nu draait.

Hoe Mole omgaat met apps die via pkg zijn geïnstalleerd

Als je een app verwijdert in Mole, leest het de installatiebewijzen waarvan de namen passen bij de bundle-identifier of productnaam van de app en toont het de paden daaruit die nog bestaan, maar alleen binnen een smalle set: de app-bundel in Programma's, en onder /Library alleen de mappen Application Support, Caches, Logs, PrivilegedHelperTools, WebKit en HTTPStorages, plus plists van Preferences, LaunchAgents en LaunchDaemons, genoemd met die exacte bundle-identifier. Die rijen komen niet aangevinkt binnen, dus je vinkt elke rij aan nadat je die hebt gelezen. Paden onder /Users, /opt, /usr en /private worden nooit rijen vanuit een installatiebewijs, en de bewijsbestanden zelf ook niet.

Nadat de app weg is, schrijft Mole het installatiebewijs dat naar de bundle-identifier is genoemd uit de catalogus, met de spelling die pkgutil op schijf heeft, en een leveranciersbewijs dat het vindt via pkgutil --file-info, dat laatste alleen als geen van de bestanden die dat bewijs noemt nog bestaat. Het doet dit alleen als de beheerderhelper al voor die verwijdering was geautoriseerd, dus het vraagt nooit een extra wachtwoord voor een installatiebewijs. De leverancierszoekactie slaat de bewijzen com.apple.* van Apple over.

De grens is de grens die hierboven is beschreven. Omdat pkgutil --file-info op macOS 27 zelden antwoordt, kan een installatiebewijs waarvan de ID niets met de app te maken heeft blijven staan nadat Mole die verwijdert, zoals de twee van DisplayLink en die van Zoom deden. Het zijn alleen verslagen, en sudo pkgutil --forget ruimt ze op. Voor drivers, VPN-clients en beveiligingssoftware is Mole geen vervanging van het verwijderprogramma van de leverancier.

Veelgestelde vragen

Verwijdert pkgutil --forget de app?

Nee. De handleiding zegt dat het alle bewijsgegevens van het pakket weggooit maar de geïnstalleerde bestanden niet aanraakt. Draai het nadat de bestanden weg zijn, nooit in plaats van ze te verwijderen.

Kan ik elk bestand verwijderen dat pkgutil --files noemt?

Nee. De lijst bevat systeemmappen zoals Library en Applications, frameworks die andere apps van de leverancier laden, en plists voor taken die nog kunnen draaien. Gebruik die om te vinden wat je bekijkt, en verwijder daarna wat alleen bij dit product hoort.

De app is weg, maar pkgutil --pkgs toont die nog. Is die nog geïnstalleerd?

Niet per se. Bestanden verwijderen werkt het installatiebewijs nooit bij, dus het blijft tot iemand het uit de catalogus schrijft. Draai de controlelus hierboven: bestaat niets dat het bewijs noemt nog, dan is alleen het verslag over en verwijdert sudo pkgutil --forget dat.