Is haiku prepared for this?
Regardless of whether the software is native or was ported!
Couldnât you just insert the installation media again/format the disk?
Obviously there should probably be an option to wipe the existing Haiku installation, but the abovementioned solution should do.
I think thatâs an habit with other OS but itâs not necessary on Haiku.
If you want to uninstall an app completely, you have just to remove the package of that app. The only things remaining after that are eventually configuration files which you can generally find and delete in home/config/name_of_app folder.
And of course, remains documents that you created with the app but I believe that those are things that you want to keep.
There are currently no way to completely automatically uninstall software. First problem is system donât know location of software config files, it should be deleted by hand. Second problem is when you install packages with dependencies, dependencies are installed automatically but it canât be removed automatically. System currently donât track which packages are installed by user request and which are installed automatically (#15567). Dependencies should be removed by hand.
@Starcrasher @X512
Then I have the same with Haiku as with Windows (and Linux?), only a little different?
It should be possible to teach an operating system to control/document the installation process of a softwareâŚ
Thatâs not completely true, the settings files are declared in the packages headers. So the package kit could be told to remove it. Then we have to make sure the declaration in the packages is correct.
For a single piece of software, you just remove it from /system/packages (or use haikudepot/pkgman). Whatâs missing is knowing which packages are from the initial install (which has also optional packages that you can add/remove), and what is from later.
Note that in current nightlies the Installer does what you need: installing over an existing install without formatting will clear out all packages and settings, but keep your data.
Personally I want to have user-requested software list in addition to activated packages. It will contain packages requested by user and when some package will be removed from list, all packages that are no longer required to any package in user-requested package list will be automatically deleted. Also compared to activated packages, user-requested list will be short and easy to understand, it will not contain a lot of small libraries like libpng that user donât care.
If user will add some ported software with a lot of dependencies (like software from KDE) to user-requested list, all dependencies will be automatically installed. And if user will remove that software from list, all dependencies will be automatically uninstalled.
activated-packages = requested-packages + ResolveDependencies(requested-packages)
3 Likes
Initially we did not want to do that because it was related to the Linux âdependency hellâ. Native applications should have few dependencies because they rely on the core OS to do most of the work.
But we got the dependency hell anyway from all the ported software 
so we will need the tools to manage it, indeed.
One thing I had experimented with is identifying âleafâ packages, the ones that nothing else depends on. It seems a good way to approximate this, even if the real thing of having a âmanually installed/pinnedâ marker somewhere is probably better. It could be a simple FS attribute on the package files set when they are installed (by the package kit, I guess?)
1 Like
This can be actually used instead of package list file. For example create boolean attribute âpackage:isRequestedâ, add it to index and query for all user-requested packages. The same thing can be done with current âactivated-packagesâ. But I am not sure how old states should be handled in this case.
A deinstall script placed in the hpkg files could be an option. At removing running the script before.
One a developer really knows there all his files copy or created are
I was (originally, but recently) annoyed about this:
- uninstall digiKam (because âsomethingâ does not seem to work properly)
- restart Haiku
- reinstall digiKam
- everything is as beforeâŚ
Searchâ shows that there is still a lot of digiKam (see ScreenShot, in this case rubbish - because thatâs where the cause for the malfunctioning is to be suspected) under Haiku.
If at least it would be possible to âselect allâ and then DELETE, but it doesnât work (system directories are deleted âalsoâ).
An OS for end users should clearly do more (then Windows and Linux)!
It should be more pleasant for the user in many (also small) things
I am curious to know which solution will be chosen.
Good luck with the implementation!
Translated with www.DeepL.com/Translator (free version)
Letâs see what we have here
You can eliminate folders 3, 5 & 6 They are entries used by HaikuDepot to display digkam packages with their icons in package list.
Files 2 & 3 , they are content of old states created by HaikuDepot when you removed digikam package, twice.
File 7 is the digikam icon so the program looks good in the menu.
File 8 is obviously the query you just made for that screenshot.
File 10 is mime database entry to know what files can be associated with digikam.
What really belongs to digikam then?
Folder 2 is the cache folder used by digikam and is empty.
Folder 1 is a folder used by digikam to store configuration files.
Folder 3 is another folder used by digikam to store configuration files. This is common with Qt apps. Some apps like Otter or Photonic are managing to put folder 1 into folder 3. I wonder why itâs not more commonly done.
Files 1 & 7 are digikam configuration files located in configuration folder as expected.
Files 6 & 9 are digikam databases. File 6 is the main database, file 9 is for thumbnails as you can guess. These are big files and package should propose to delete them when uninstalling.
Finally file 4 has a path that is personal so I guess that you created this one.
So, only things that you need to delete to have it clean are files 6 & 9 (the databases) , folder 1 & 3 and their content (configuration folders and files).
Thank you Starcrasher, for this detailed answer!
Thanks also to all who are concerned with the problem and think of solutions - maybe even (want to) work on it!
I have deleted EVERYTHING that had digiKam on it. Now it works much better.
But digiKam is not (also) a paragon of user-friendliness!
Maybe it will improve with version 7.2.x - I really hope so!
As far as the deninstallation itself is concerned, I wish for the optimum, but I donât expect it in any case!
In the end there will be some queries that the user has to answer. But please in an understandable form for everyone!
Translated with www.DeepL.com/Translator (free version)
Some info for how this is done in Linux-world (specifically dpkg):
- dpkg has separate uninstall (remove the program, keep all settings) and purge (remove all settings) commands. Should these two be distinguished as well in Haiku, or should we do one or both?
- If weâre going with only one, I suggest both uninstalling and purging, as reinstall seems to be a common tactic to deal with weird config problems
- dpkg marks each package as either âmanually installedâ or âautoinstalledâ (dependency) - just like suggested above. Autoinstalled packages that are not used arenât uninstalled automatically, but can be uninstalled by a single command.
But how to handle this? Hpkgs are mounted as virtualized objects. If we have a dpkg next by hpkg we get the doubled package number. Too many virtualized packages can slow down the system?
I think a deinstall script in the hpkg, running automatically by removing or deinstalling are the better way.
I think that declarative way (list of config files/folders location) to delete settings is better than imperative (scripts on delete). Scripts are dangerous and they can delete something wrong.
And Who declarate the files and paths in a dpkg? Is this not the same at the end? Only the software creator knows that files and folders really installed and created on the system. A automatation can break more, because it could delete files used of more then one program.