On 9/5/21 4:31 pm, Mechtilde wrote:
My conclusion is that application plugin mangers should make use of the platform installation process for installing and uninstalling plugins as it would appear that 'deb' install packages cannot ever do a proper clean up of software they have installed, and by implication, allowed to be installed. This would appear to be more to do with the sanctity of $HOME, i.e. you can put stuff in there but must never remove stuff, than the actual practicality of doing so. This hints that $HOME is not the correct location to put executable and binary support data (non-user modifiable) as it is not supportable nor maintainable.Hello Jon, which plugin manager are you talking about. Each application providing plugins has its own mechanism to handle them. So i don't understand what your conclusion is. So I want to know whether my packages can be affected or benefit of it. Regards Mechtilde Am 08.05.21 um 23:50 schrieb Jon Gough:On 8/5/21 10:51 pm, Sven Hartge wrote:Jon Gough <jonsgough@gmail.com> wrote:So, any user installable application extension/plugin which has executables and supporting data is left behind on the system when the owning application is removed or updated using the system installation process? This is accepted behaviour?Yes, this is accepted behaviour, because the system does not know if the user uses the file for anything else. Maybe $HOME is mounted from the network and the application using the files is still being used on a different system.Shouldn't applications clean up after themselves and not leave user systems with junk lying around?No. Grüße, S°This suggests that for most plugins the plugin manager should facilitate finding and installing the plugins and should probably have two installation methodologies, one for simple plugins with very small executable and data (non-user) footprint and one for complex plugins with large executables and/or data (non-user). The simple one could be based on unzipping a file and placing it in the $HOME directory structure, the complex one could be based on 'deb' using system services to install the plugin in system areas and only having user data in the $HOME directory structure. This would then allow the system to manage the removal of the non-user components when/if the main application is removed. Thanks for your help in clarifying this. Jon
It should be quite simple to have the 'deb' uninstall process start an 'application process' that knows all packages that have been installed and allow them to be uninstall if the user wishes. But this again is not considered acceptable. However, leaving programs and binary non-user data on the device is considered acceptable. This is an interesting concept for phone and tablet devices which are resource constrained.
I now know what path I need to follow, i.e. have a plugin manager that uses the platform installation process so that the uninstall process will work and the packages and objects will be tracked.
Thanks