On 5/6/21 5:36 pm, Andrey Rahmatullin wrote:
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 plugin manager does not use deb's, the main application the plugin
manger is a part of is installed/uninstalled/removed from a deb.
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.
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.
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.
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:
*Package selection states
....
purge* The package is selected to be purged (i.e. we want to remove
everything from system directories, even configuration files).
And in the options to dpkg:
ACTIONS
....
-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.
These 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.
