Hi List,
I am working on a user driven plugin management process for an application which is installed via a 'deb' file. The application is
installed using 'root' privileges, but the plugins need to be
installable by the user without root privileges. The plugins will
consist of libs, icons, etc. that are used to 'run' the plugin and user updateable config files used to 'control' the plugin.
If the plugin was installed by a 'deb' file it would put libs and supplied icons in a system area, i.e. /usr or /usr/local, and the
updateable config files in a user writeable area, i.e.
$HOME/.<application>/. What would be a suitable location for the libs,
icons, etc. for the user installed plugin?
Many thanks
Jon
Hi Jon,
Maybe it would be preferable to use the XDG recommendation ?
App configuration, and plugins configuration too: XDG_CONFIG_HOME:-$HOME/.config/[MyTLD]/[MyApplication]/
User installed plugins resources: XDG_DATA_HOME:-$HOME/.local/share/[MyTLD]/[MyApplication]/
*where MyTLD is a top-level unique 'domain' that avoids name clashing
between apps.
More to read here:
https://www.freedesktop.org/wiki/Specifications/
HTH,
Benoît
Le 06/05/2021 à 01:36, Jon Gough a écrit :
Hi List,
I am working on a user driven plugin management process for an
application which is installed via a 'deb' file. The application is
installed using 'root' privileges, but the plugins need to be
installable by the user without root privileges. The plugins will
consist of libs, icons, etc. that are used to 'run' the plugin and
user updateable config files used to 'control' the plugin.
If the plugin was installed by a 'deb' file it would put libs and
supplied icons in a system area, i.e. /usr or /usr/local, and the
updateable config files in a user writeable area, i.e.
$HOME/.<application>/. What would be a suitable location for the
libs, icons, etc. for the user installed plugin?
Many thanks
Jon
Hi,
Thanks for the info, I thought this may be the case. Using that it is
easy to install and uninstall plugins from the main program. The uninstall can be just the plugin resources or the plugin resources and configuration items as well and we can ask the user what level of uninstall they intend.
One thought though, what happens if the main application, the 'deb', is uninstalled? Should the plugin resources be left or uninstalled, what about the configurations?
Once the main app has been uninstalled there is no way
for the user to easily uninstall/remove left over stuff. As far as I can see most users only know about Downloads, Documents, etc., but nothing about directories that contain '.' as the leading character (most desktops hide these directories).
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?
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 by plugins? Debs will identify dependencies that are no longer required when they are uninstalled and
the system package manger will allow automatic uninstall of unused items
if the user wants.
The use of .local and .config is not an issue when installing, but it is during the un-install process that the issue arises. My experience of
users is that they know little of the file system and only really
recognise 'Documents', 'Downloads' and 'Desktop' as being places where
things are stored. I know of users who upgrade phones/tablets/PC's
because they become 'slow' due to left over items filling all available
disk space. I am hoping to be a little more user friendly than that. The whole purpose of the plugin manager is to allow users to extend the capabilities of the application without having to worry about the 'deb' install processes.
Most of the instances of the program will be installed for use on
'single user' or 'single user account' machines. The cases where a
machine is 'multi user' will likely be developers or being 'managed' by
ICT people so that will not be an issue. In normal user cases they will
use a package manager to uninstall the package and will not go near a
command prompt.
Jon
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?
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 by plugins? Debs will identify dependencies that are no longer required when they are uninstalled and the system package manger will allow automatic uninstall of unused items if the user wants.
The use of .local and .config is not an issue when installing, but it is during the un-install process that the issue arises. My experience of users is that they know little of the file system and only really recognise 'Documents', 'Downloads' and 'Desktop' as being places where things are stored. I know of users who upgrade phones/tablets/PC's because they become 'slow' due to left over items filling all available disk space. I am hoping to be a little more user friendly than that. The whole purpose of the plugin manager is to allow users to extend the capabilities of the application without having to worry about the 'deb' install processes.
Most of the instances of the program will be installed for use on 'single user' or 'single user account' machines. The cases where a machine is 'multi user' will likely be developers or being 'managed' by ICT people so that
will not be an issue. In normal user cases they will use a package manager
to uninstall the package and will not go near a command prompt.
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?
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 by plugins?
Jon Gough 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 $HOME.
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 by plugins?
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.
-kgd
On 8/5/21 12:17 am, Kris Deugau wrote:
Jon Gough 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 $HOME.
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 by plugins?
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.
-kgd
Hi,
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?
</div></div></div>
On 8/5/21 12:17 am, Kris Deugau wrote:
Jon Gough wrote:
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 by plugins?
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.
Hi, 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?
  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?
Jon Gough <jonsgough@gmail.com> wrote:
  So, any user installable application extension/plugin which hasYes, this is accepted behaviour, because the system does not know if the
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?
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 userNo.
systems with junk lying around?
Grüße,
S°
Hello Jon,My conclusion is that application plugin mangers should make use of the platform installation process for installing and uninstalling plugins as
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:This suggests that for most plugins the plugin manager should facilitate
   So, any user installable application extension/plugin which has >>>> executables and supporting data is left behind on the system when theYes, 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
owning application is removed or updated using the system installation >>>> process? This is accepted behaviour?
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 userNo.
systems with junk lying around?
Grüße,
S°
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
On 8/5/21 10:51 pm, Sven Hartge wrote:
Jon Gough <jonsgough@gmail.com> wrote:This suggests that for most plugins the plugin manager should facilitate finding and installing the plugins and should probably have two
   So, any user installable application extension/plugin which hasYes, this is accepted behaviour, because the system does not know if the
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?
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 userNo.
systems with junk lying around?
Grüße,
S°
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
On Fri, May 07, 2021 at 10:58:27AM +1000, Jon Gough wrote:
The user install plugins can vary between very simple with a config fileand
a couple of icons up to complex with large data >1GB and hundreds oficons.
So, if debs must not touch files in $HOME but is allowed to create files there (is that not a contradiction?)
Sorry if my wording was not precise enough:
Packages are not allowed to do that either. The only way a package
might modify $HOME if the user owning $HOME started a program in the packages. touch in my sentence != touch(1).
where else could the 'system' files be placed?
Not sure what you mean about system files.
My interpretation would be that "system" files come from the .deb. Here, Debian policy is the reference, and §9 refers to the FHS with
execptions. This is probably what you need to read to answer your
question, if I got you right.
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
(However, a regular user has not means to install something outside of $HOME.)
Is there a process that allows the deb to 'clean up' the application when the application is uninstalled, in particular any 'install' artefactsthat
have been installed by plugins? Debs will identify dependencies that areno
longer required when they are uninstalled and the system package mangerwill
allow automatic uninstall of unused items if the user wants.
I'm not aware that such thing exists. (read:I'm pretty sure it does
not.) And would it be even possible? Starting already with the question
how would you ask _ALL_ the affected users at apt remove-time. And what
is if the user has got a crypted home or the $HOME/.config $HOME/.local
is on a network share … … … … … … … … …
The use of .local and .config is not an issue when installing, but it is during the un-install process that the issue arises. My experience ofusers
is that they know little of the file system and only really recognise 'Documents', 'Downloads' and 'Desktop' as being places where things are stored. I know of users who upgrade phones/tablets/PC's because theybecome
'slow' due to left over items filling all available disk space. I amhoping
to be a little more user friendly than that. The whole purpose of theplugin
manager is to allow users to extend the capabilities of the application without having to worry about the 'deb' install processes.
You'll be most friendly to the users if you stick to standards.
If you do something special, the users will to have to suddenly know
your speciality. Imagine the mess if every package does it differently. Novice users will be screwed, all common $searchengine-able solutions
won't work anymore. Expert users will be constantly facepalming and
likely fire up reportbug(1) with constantly swearing "WTF?" to themselves.
Most of the instances of the program will be installed for use on 'single user' or 'single user account' machines. The cases where a machine is'multi
user' will likely be developers or being 'managed' by ICT people so that will not be an issue. In normal user cases they will use a packagemanager
to uninstall the package and will not go near a command prompt.
Nope, that is not how packaging for Debian works.
Debian being the universal operating system has so many uses cased, not
only single-user or multi-user. There are also no special for-developer-only-deb-flavours and people might or might not use the
cli; How would you tell that this is a developer machine? How would you
tell that the user is using a GUI or not. Your package must not behave differenlty only because it was installed differently…
--
tobi
PS: It makes it harder to response if remove the context. It is suggested
[1]
to use the interleaved style[2].
[1] https://wiki.debian.org/DebianMailingLists#Posting_Rules.2C_Guidelines.2C_and_Tips
[2] https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
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?
would appear that 'deb' install packages cannot ever do a proper clean up of software they have installedThis a) sounds worse than it is, b) is not specific to debs and instead
This hints that $HOME is not the correct location to put executable and binary support data (non-user modifiable)This is not true, browsers and things like IDEs do that all the time and
However, leaving programs and binary non-user data onUsers of space-constrained systems should clean up the files they no
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 workIf this means calling apt from a plugin manager then it's probably not the
and the packages and objects will be tracked.
where else could the 'system' files be placed?
Not sure what you mean about system files.
My interpretation would be that "system" files come from the .deb. Here, Debian policy is the reference, and §9 refers to the FHS with
execptions. This is probably what you need to read to answer your question, if I got you right.
The debian policy manual also mentions plug-ins in section 10.2.Only about specifics of linking plugins that are ELF libraries, which is
On 9/5/21 4:31 pm, Mechtilde wrote:
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 hasYes, this is accepted behaviour, because the system does not know if the
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?
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
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.
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.
On 9/5/21 5:40 pm, Andrey Rahmatullin wrote:
On Sun, May 09, 2021 at 04:41:13PM +1000, Jon Gough wrote:
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, i.e. phone, tablet, etc.. Even when on a multi
user device, i.e. windows, the device is still only used by one
account.
If the uninstall process is run for the main application any other
account using the machine will have issues if they expect the main application to still be there. So, in this case uninstalling plugins
during the main uninstall process would not be a major issue. The
config files/data would not be uninstalled/removed by this process.
On Sun, May 09, 2021 at 04:41:13PM +1000, Jon Gough wrote:No, in this case it is a deb.
My conclusion is that application plugin mangers should make use of the"the platform installation process" sounds like using debs, am I wrong?
platform installation process for installing and uninstalling plugins as it
Most users have no concept of how to do this, they just buy anotherwould appear that 'deb' install packages cannot ever do a proper clean up of >> software they have installedThis a) sounds worse than it is, b) is not specific to debs and instead
is true for all or almost all software installation ways out there, except for heavily containerized things.
This hints that $HOME is not the correct location to put executable andThis is not true, browsers and things like IDEs do that all the time and
binary support data (non-user modifiable)
it works as expected.
However, leaving programs and binary non-user data onUsers of space-constrained systems should clean up the files they no
the device is considered acceptable. This is an interesting concept for
phone and tablet devices which are resource constrained.
longer need manually, preferably using tools that show the space distribution.
Not quite. The plugin manager needs to keep track of what it hasI 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 workIf this means calling apt from a plugin manager then it's probably not the best idea.
and the packages and objects will be tracked.
The Wanderer <wanderer@fastmail.fm> wrote:Yup, but these users are in the minority. At uninstall, given the choice
I genuinely do not see what insisting on uninstalling plugins at theAlso beware of strange stuff the user may have done to the data in
same time as the main program, for all user accounts, provides as a
benefit. The only maybe benefit I've seen suggested is cleaning up to
free disk space, and that seems to me to be so obviously heavily
outweighed by the other considerations that it should clearly not be
the deciding priority.
$HOME.
On one of the multi-user systems I admin for my University one user had placed a symlink to /usr/bin as $HOME/bin and another symlink to / as $HOME/root. I have no idea as to *why* but imagine the fun you can have
if you just naivly delete something following symlinks.
Grüße,
Sven.
I genuinely do not see what insisting on uninstalling plugins at the
same time as the main program, for all user accounts, provides as a
benefit. The only maybe benefit I've seen suggested is cleaning up to
free disk space, and that seems to me to be so obviously heavily
outweighed by the other considerations that it should clearly not be
the deciding priority.
On 2021-06-04 at 17:43, Jon Gough wrote:They use the 'Play Store' app on an android phone so no nothing of apt.
On 9/5/21 5:40 pm, Andrey Rahmatullin wrote:I'm... fairly sure that the uninstall process must not touch the
On Sun, May 09, 2021 at 04:41:13PM +1000, Jon Gough wrote:Not quite. The plugin manager needs to keep track of what it has
I now know what path I need to follow, i.e. have a plugin managerIf this means calling apt from a plugin manager then it's probably
that uses the platform installation process so that the uninstall
process will work and the packages and objects will be tracked.
not the best idea.
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.
contents of user directories, not even indirectly by invoking an
external program (such as this plugin manager) which would do so on its behalf. If I'm wrong, someone may correct me, but I would be surprised
if it were that easy to bypass this constraint on package design.
In most instances the main application is installed on devices thatHow can you possibly be sure about that?
have only one user, i.e. phone, tablet, etc.. Even when on a multi
user device, i.e. windows, the device is still only used by one
account.
(Also, if someone is installing packages on a tablet or smartphone via
apt, they are very likely sufficiently expert to have some idea of how
to clean up after the uninstall as needed; if there's a device in those categories which uses apt for native install mechanisms, rather than as
an aftermarket extra tool, I'm not aware of it.)
They get asked if they want to do a complete uninstall of all downloaded plugins, or leave themIf the uninstall process is run for the main application any otherAnd what if the user is uninstalling, but intends to install again
account using the machine will have issues if they expect the main
application to still be there. So, in this case uninstalling plugins
during the main uninstall process would not be a major issue. The
config files/data would not be uninstalled/removed by this process.
later (maybe even right away)? To have to re-download and reinstall the plugins could easily be a significant irritation, at the least.It should be a user choice not a developer decision. However, offering
Personally, I would probably see the plugins as being part of the
program configuration; certainly I do so with e.g. the Firefox
extensions I use.
I genuinely do not see what insisting on uninstalling plugins at the
same time as the main program, for all user accounts, provides as a
benefit. The only maybe benefit I've seen suggested is cleaning up to
free disk space, and that seems to me to be so obviously heavily
outweighed by the other considerations that it should clearly not be the deciding priority.
On 9/5/21 5:40 pm, Andrey Rahmatullin wrote:An "application plugin manager" installing debs sounds wrong.
On Sun, May 09, 2021 at 04:41:13PM +1000, Jon Gough wrote:No, in this case it is a deb.
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?
If previously we were talking about generic things that include DebianMost 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.However, leaving programs and binary non-user data onUsers of space-constrained systems should clean up the files they no
the device is considered acceptable. This is an interesting concept for phone and tablet devices which are resource constrained.
longer need manually, preferably using tools that show the space distribution.
Yeah, wrong mailing list.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,I now know what path I need to follow, i.e. have a plugin manager that usesIf this means calling apt from a plugin manager then it's probably not the best idea.
the platform installation process so that the uninstall process will work and the packages and objects will be tracked.
On 5/6/21 7:59 am, The Wanderer wrote:
And what if the user is uninstalling, but intends to install againThey get asked if they want to do a complete uninstall of all downloaded plugins, or leave them
On Sat, Jun 05, 2021 at 07:43:54AM +1000, Jon Gough wrote:The plugin manager does not use deb's, the main application the plugin
On 9/5/21 5:40 pm, Andrey Rahmatullin wrote:An "application plugin manager" installing debs sounds wrong.
On Sun, May 09, 2021 at 04:41:13PM +1000, Jon Gough wrote:No, in this case it is a deb.
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?
The deb install of the main program is used on Raspberry Pi's as well asIf previously we were talking about generic things that include DebianMost 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 nothingHowever, leaving programs and binary non-user data onUsers of space-constrained systems should clean up the files they no
the device is considered acceptable. This is an interesting concept for >>>> phone and tablet devices which are resource constrained.
longer need manually, preferably using tools that show the space
distribution.
about.
this seems to be talking about things that *don't* include Debian.
Why? The question is about cleaning up files when a deb package isYeah, wrong mailing list.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 toI now know what path I need to follow, i.e. have a plugin manager that usesIf this means calling apt from a plugin manager then it's probably not the >>> best idea.
the platform installation process so that the uninstall process will work >>>> and the packages and objects will be tracked.
uninstall one or more plugins. In most instances the main application is
installed on devices that have only one user,
On 6 Jun 2021, at 20:51, Jon Gough <jonsgough@gmail.com> wrote:
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.
Hi again, Jon!That sounds like a solution putting the large binary read-only files in
On 6 Jun 2021, at 20:51, Jon Gough <jonsgough@gmail.com> wrote:Not at all, because packages do not install any files to any user-$HOME.
These suggest that a full cleanup could/should(?) be done including all user generated files.
If the user generated (or triggered the generation of) any files, by definition the package-installer didn't create them,
and by policy and following "the law of least surprise" the package-uninstaller shouldn't touch them.
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.Two different approaches I've used for this situation over the decades have worked well for me.
Not sure if either will be an improvement for you.
1/ Have the package-installer emplace a pseudo-group, with the plugin-manager set-group to that pseudo-group.
Then, chgrp anything created for the user into his $HOME to that pseudo-group. The user-invoked script to clean up $HOME
then just has to look for file-system entries with that group.
2/ If you're absolutely dead-set on forcing clean-up of per-user files, *whether or not the user wants them cleaned up*,
then just don't put anything in any $USER-home. Problem solved. Then, take your cue from {mail,news,uucp,cups,ftp,...}
and keep all per-user files off in /var/spool/plug-package/ and/or a pseudo-user "home directory". On package-uninstall,
make sure /var/spool/plug-package/ and pseudo-user "home directory" get cleared and removed. (This is where you'd differ
from {mail,news,uucp,cups,ftp,...} -- they won't clear and remove [or at least didn't the times I looked from ~1990 onward].)
Trade-off between 1/ and 2/ is "where do the files live" and "how much must the package harden itself from user interference".I am not set on any particular location and have been put off $HOME by
If you're dead-set on using space in each user's $HOME, option 1 it is. Doing that means your package has explicitly given-over
custody of those files to the user, since they're in the user-controlled space. Your package has to have the user trigger clean-up,
using commands your package provides documented by your package. Your plugin-manager also has to self-repair any changes
made by the user in his file-space, since it's the user's file-space not yours and he'll do whatever he darn well pleases there.
If it's just you want to make use of disk-space available on /home/ go ahead with option 2 and pseudo-user homed on /home/.
Thanks!
Joseph
——
Joseph Beckenbach
+1-678-602-3192 (EST/EDT)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 63:20:48 |
| Calls: | 6,654 |
| Files: | 12,200 |
| Messages: | 5,331,697 |