On Fri, 7 May 2021, 08:35 Tobias Frost, 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
>
>
>
