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 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?)
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.
The debian policy manual also mentions plug-ins in section 10.2.
AFAIK packagess should not install or uninstall files into $HOME. But nothing prevents the package from installing a program or script that can do so when the program is invoked by a real user.
Or you mean something like what this tries to solve:
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' 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.
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 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.
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 package manager
> 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