Re: Location for user installed plugin libraries and icons
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.
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.
Am 08.05.21 um 23:50 schrieb Jon Gough:
On 8/5/21 10:51 pm, Sven Hartge wrote:
Jon Gough <firstname.lastname@example.org> 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
Shouldn't applications clean up after themselves and not leave user
systems with junk lying around?
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
Thanks for your help in clarifying this.
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.