[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Location for user installed plugin libraries and icons



Am Sun, May 09, 2021 at 04:41:13PM +1000 schrieb Jon Gough:
> 
> 
> 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 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
> > > > 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.

Not necesarlly. I would say it needs to be distribution-aware, but not
necessarily integrating with "plattform installation process." See below.

> 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,

As this read ambiguous to me, lets make sure we both are on the same page:
You are NOT allow to put thing in $HOME _at package installation time_
Only your program / plugin manager / etc may do so after the user
associated with $HOME has started it.

> than the actual practicality of doing so.

(ambigity continued) The package manager would have NO safe method to
remove files in any $HOME directory. so it is not practicabel for the
package manager anyways.

> 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.

Handling memory constrained devices is not the scope of a packaging manager.
It will also not handle such things on non-constrained devices.

There is software that will warn you when free space is getting low, but
it will also only warn you and maybe start a tool to investigate the situation.

(Mobile platforms have completly different approaches, completly other
concepts, more container-like. This is not at all comperable to Debian.)

> 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.

Not necessarily. You can of course check if there are packaged plugins available,
and hint the user to install that one, but keep also in mind:
- The user might have not the required privileges to do so.
- The user might want to have a different plugin version, not available (yet) or
  even not available in their distribution at all (e.g user on stable)

so, I guess, you maybe want to hint only that there is a packaged version, but
let the user also install from other sources.

You might want to take a look at how gnome-shell-extensions, firefox addons etc
are handled: Their search paths for plugins include the installation directories
for packaged extensions/plugins/etc, but they also look in $HOME. They won't invoke
apt install or like. They also do NOT the hinting thing.

(Generally, maybe a good advice is how similar software in Debian is
doing such things and get inspired from them… I don't think there is a
need to reinvent things.)


(* The hinting might actually be a good idea; at least on one of my
  gnome-shell- extension's upstream gets a lots of bugs of people
  installing from gnome directly, just to find out that the one on gnome
  is too new for Debian. But having the information in the README of
  upstream reduced that bug rate)

-- 
tobi


Reply to: