Package Uninstall should run a Bash Script too

[AGMS]

There's a .PackageInfo keyword for "post-install-scripts" which comes in useful for making desktop icons (a symbolic link to the executable in the user's desktop folder) and other installation type activities. It would be useful to have a "pre-uninstall-scripts" entry too, so we can undo things that were done during install (like removing desktop icons).

[Giova84]

I would like to point out that the post-install-script is also useful not only for making desktop icons and links (and more generally, to write files outside of the read-only directories), but also to display a notification after that a package has been installed, since currently, after that a package has been installed, there is a "total silence". As example I achieve this by using

notify --type important --group "Package Installation" --title "Done" --timeout 8 --icon /boot/system/apps/Installer "Wonderful package successfully installed"

(I filed this enhancement on ticket:13413)

Your suggestion for "pre-uninstall-scripts" would be also very useful, and I think of this since a long time, so "+1" for your idea.

[AGMS]

Some test packages with the new pre-uninstall-script keyword, and compiled .hpkg files using an updated 2.1 package file format (won't be useable on the current 2.0 packaging system).

[AGMS]

Code patch submitted to ​https://review.haiku-os.org/c/haiku/+/1504

[AGMS]

A backwards compatibility code patch so older Haiku can handle newer packages (same major version, different minor version) is at ​https://review.haiku-os.org/c/haiku/+/1714

[lelldorin]

I like the idea of add a uninstall script into packages, because many programs use extended files they never uninstall too.

But this need to be selectable, because you do not want to uninstall this files every time.

So a script is a good idea.

The most bad deinstall routine are like deinstall the yab binary for example. Here all programs using yab are delete from the system. If here would all user files delete...

[AGMS]

That's more up to the person writing the uninstall script. They could prompt the user to see if they wanted to delete their files. Or at least use "trash" rather than "rm" to delete user files.

[X512]

I think that any kind of prompts in install/unintall scripts should be never used. Packages can be installed from command line and GUI that require different interface, packages can be also installed/uninstalled in automatic mode without user interaction.

Package should delete all its config/caches on uninstall or add ability to delete it after uninstall otherwise garbage files will grow. One of possible solutions is add file system attribute identifying package to all config files/folders. BFS query can be used to quickly delete all config for package.

[lelldorin]

I think we do the fast an easiest way to deinstall all userfiles. So we have a quick and dirty way gone, we really should do what?

An example: The user install a Mail app The app goes broken The user deinstall the app to reinstall it Then he start the app and no Mails, drafts... anymore!

Second example: The user play a game and end the game He wants to deinstall the game but not the save gamedata.

Yes we should not fill up the system with trash, but we need to think like a user here please.

I am with AGMS, individual uninstallscripts are the bests solution.

If a user install a hpkg over the shell, it works like in haikudepot. I see here no problem and if we do a good description to the uninstall way, people with non-hpkg solutions can use this way too if we add a fixed folder for the uninstallscripts in non-packaged too or it will be installed to the uninstallscripts folder using pkgman.

Here we should think about it.

[X512]

Replying to lelldorin:

The user install a Mail app The app goes broken The user deinstall the app to reinstall it Then he start the app and no Mails, drafts... anymore!

Mail is stored in user folder, not in config so no problem here. Also if mail app become broken because of bad config, reinstall don't help until config will be deleted.

Second example: The user play a game and end the game He wants to deinstall the game but not the save gamedata.

This seems to be valid case. As I described above attributes can be used to identify owner package of config. Another approach is specify path to config in ".PackageInfo".

Removing files in uninstall script is unreliable solution, because it can contain errors and delete more/less then needed causing user data damage. It also do not allow do delete config after package was uninstalled because uninstall script is uninstalled too.

[lelldorin]

Ok an other example: I create some packages of old games and programs (be) to use on haiku. To make this games and programs runable they need files in writeable folders. This files need to unzip to this positions, because you can not install to home or config in home using hpkg. This files need to deinstall too, but a hpkg does not know there and that files. This can only manage the package builder.

And not every user use haiku ports at all.

[AGMS]

I'm not sure that user file deletion should be in the uninstall script. When doing an update it will uninstall the old version and install the new version. It would be kind of annoying to have files deleted then. Better to have cleanup-user-files as a menu item in the deskbar, which just fires off a shell script. Or if you want to get weird, trash the files on uninstall, restore them from trash on install.

Anyway, that's more of a policy on what an uninstall script should do. Which can be summed up as not annoying the user. We just need to have a mechanism to run a script on uninstall.

[nephele]

Deinstall scripts should /never/ touch config or user data imo, whether you use haikuports or some other package repository is pretty irrelevant.

This files need to unzip to this positions, because you can not install to home or config in home using hpkg.

Yes you can? That is how haikuporter operates, no? It's just not the default, if you need writeable locations patching the software, or using a sort of unionfs makes the most sense for a clean solution imo.

Android cleans up data applications write, and personally i absolutely hate this, i have lost data severall times dou to it (It associates data via unix users for the shared space)

For the case of leftover data, like highscores, old mails etc. that users may want to deinstall there should be a "Cleanup" utility later of sorts that lists folders created in ~/config/ that are associated with deinstalled apps, to offer users an easy way to remove this on a case-by-case basis (This is after all user data, and users should decide what happens with it)

(As an example Vision for instance keeps logs, those should be offered to be deleted in such a utility somewhere down the line)

[lelldorin]

I think to add the posability to run a deinstall script is the best way.

The package creator should know that he install and that can be deinstalled from writeable areas like gamefiles, config files.

A good packager should ask the user before removing files and/or config files too.

I will do and handle like this and would be afraid about it.

[pulkomandy]

Patch has been merged.