On 8/5/21 12:17 am, Kris Deugau wrote:
The user install plugins can vary between
very simple with a config file and a couple of icons up to
complex with large data >1GB and hundreds of icons.
So, if debs must not touch files in $HOME but is allowed to
create files there (is that not a contradiction?) where else
could the 'system' files be placed?
The actual .deb *package* (by way of the programs that
install/uninstall packages) may not make changes to files under
The program *within* a .deb may (and in many cases is expected to)
create. alter, and/or delete some selection of files in $HOME.
If a plugin is to be considered a "system" addition, it must be
packaged (either with the main program, or as a separate optional
package). Otherwise it's not a system file so far as the packaging
system is concerned.
Is there a process that allows the deb to
'clean up' the application when the application is uninstalled,
in particular any 'install' artefacts that have been installed
Not really. The Firefox package, for instance, won't clear up the
leftover cache data, bookmarks, and other configuration from
users' $HOME when uninstalled - including things like addons the
user may have installed direct from the Mozilla addons site.
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? Shouldn't
applications clean up after themselves and not leave user systems
with junk lying around?
I guess what people in this thread are trying to tell you that you're supposed to package plugins as Debian packages if they're too big to be in ~/.local/; the same is true for any plugin you want to be uninstalled when the application gets uninstalled. So, if you think that leaving the plugins behind is unacceptable, you have to package it.