The plugin manager does not use deb's, the main application the plugin manger is a part of is installed/uninstalled/removed from a deb.On Sat, Jun 05, 2021 at 07:43:54AM +1000, Jon Gough wrote:On 9/5/21 5:40 pm, Andrey Rahmatullin wrote:On Sun, May 09, 2021 at 04:41:13PM +1000, Jon Gough wrote:My conclusion is that application plugin mangers should make use of the platform installation process for installing and uninstalling plugins as it"the platform installation process" sounds like using debs, am I wrong?No, in this case it is a deb.An "application plugin manager" installing debs sounds wrong.
The deb install of the main program is used on Raspberry Pi's as well as Debian & Ubuntu desktop machines. Pi's are storage constrained, but the users are not required to know much, if anything, about 'how it runs', it is access through a gui which hides the gory details and this is the way that most users use technology. My Ubuntu desktop system ran out of disk space because Google Android Studio updated and left behind a '.cache' directory with >2.5GB of binary data. I knew how to go about finding the issue, many users would not.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.Users of space-constrained systems should clean up the files they no longer need manually, preferably using tools that show the space distribution.Most users have no concept of how to do this, they just buy another device because the old one is 'broken', i.e. is full of stuff they know nothing about.If previously we were talking about generic things that include Debian this seems to be talking about things that *don't* include Debian.
Why? The question is about cleaning up files when a deb package is uninstalled and in particular when a 'purge' is used. The man page for dpkg has the following: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.If this means calling apt from a plugin manager then it's probably not the best idea.Not quite. The plugin manager needs to keep track of what it has installed and where, then during the uninstall process it can be called, if needed, to perform the cleanup as it would if the main program were calling it to uninstall one or more plugins. In most instances the main application is installed on devices that have only one user,Yeah, wrong mailing list.
Package selection statesAnd in the options to dpkg:
....
purge The package is selected to be purged (i.e. we want to remove everything from system directories, even configuration files).
ACTIONSThese suggest that a full cleanup could/should(?) be done including all user generated files. If $HOME is not allowed to be touched by convention I was trying to ascertain where else they could be located that does not require root access to create, modify, delete so that the cleanup could be done.
....
-r, --remove package...|-a|--pending
Remove an installed package. This removes everything except conffiles and other data cleaned up by the postrm script, which may avoid having to reconfigure the package if it is reinstalled later (conffiles are configuration files that are listed in
the DEBIAN/conffiles control file). If there is no DEBIAN/conffiles control file nor DEBIAN/postrm script, this command is equivalent to calling --purge. If -a or --pending is given instead of a package name, then all packages unpacked, but marked
to be removed in file /var/lib/dpkg/status, are removed.
Removing of a package consists of the following steps:
1. Run prerm script
2. Remove the installed files
3. Run postrm script
-P, --purge package...|-a|--pending
Purge an installed or already removed package. This removes everything, including conffiles, and anything else cleaned up from postrm. If -a or --pending is given instead of a package name, then all packages unpacked or removed, but marked to be
purged in file /var/lib/dpkg/status, are purged.
Note: some configuration files might be unknown to dpkg because they are created and handled separately through the configuration scripts. In that case, dpkg won't remove them by itself, but the package's postrm script (which is called by dpkg), has
to take care of their removal during purge. Of course, this only applies to files in system directories, not configuration files written to individual users' home directories.
Purging of a package consists of the following steps:
1. Remove the package, if not already removed. See --remove for detailed information about how this is done.
2. Run postrm script.