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