On Fri, 7 May 2021, 08:35 Tobias Frost, <t...@debian.org> wrote: > 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 > > >
