[SOLVED] Protecting Desktop Files in /usr/share/applications

myrlin · 2012-02-09 15:42:43

I am using Openbox/fbpanel, and I have a very irritating problem.

Fbpanel uses the desktop files in /usr/share/applications to create its launcher menu. I have edited several of these to my own requirements (hiding some applications, changing the names of some. etc). This all works fine until I carry out an update, when new versions of packages overwrite these modified files. I then have to do the modifications all over again. Very time-consuming and VERY annoying.

Does anyone have any ideas on how I can prevent this from happening?

Last edited by myrlin (2012-02-11 10:34:39)

Gusar · 2012-02-09 15:46:06

Copy the files you've changed into ~/.local/share/applications

myrlin · 2012-02-09 16:11:27

Thank you so much for your fast reply, Gusar.

So, does fpanel look in ~/.local/share/applications first, then ignore any duplicates found in /usr/share/applications?

Gusar · 2012-02-09 16:32:09

That's how this stuff is supposed to work, if a file with the same name is present in both /usr/share/applications and ~/.local/share/applicantions, the the file in ~/.local will be used. Works with lxpanel, no idea about fbpanel.

myrlin · 2012-02-09 19:18:52

Hmm...seems not!

I've just done some experiments, and I just get two entries in the menu. Looks like an fbpanel issue then?

Thanks again for your help, Gusar.

Awebb · 2012-02-09 19:24:49

For some paranoia reasons, I prefer /usr/local/* over of ~/.local/*. Pure preferencial aestetics, of course.

myrlin · 2012-02-09 20:11:33

Same result - duplicate entires.

I guess a workaround would be to transfer EVERYTHING from /usr/share/applications into a local file, delete everything from /usr/sahre/applications, then keep it empty. Seems a bit of a dirty hack, so I would be interested in anyone's views.

Thanks again to everyone for their help.

lucke · 2012-02-09 20:40:23

On ext filesystems, you can use "chattr +i filename" to stop the file from being modified.

ngoonee · 2012-02-10 01:21:56

I doubt fbpanel can edit the files in /usr/share/applications without requesting root permissions?

In any case, you could just use NoUpgrade on each file in pacman.conf

swanson · 2012-02-11 07:45:20

Preventing installation scripts from writing files seems a bit scary, I mean, it might error out? So I made this little script;

 EDIT: removed my stupid script! Much better to backup your .desktop files 
and then restore them, as suggested in this thread. 
Sometimes my scripting curiousity overshadows my logic.

I think you can restart fbpanel with; killall -USR1 fbpanel. I made it since I seem to have the same problem with .local/share/applications and /usr/share/applications, or sometimes some apps don't look in .local/share/ ... , like obmenugen.

Last edited by swanson (2012-02-13 08:31:21)

desm0tes · 2012-02-11 08:49:27

myrlin wrote:

I am using Openbox/fbpanel, and I have a very irritating problem.
Fbpanel uses the desktop files in /usr/share/applications to create its launcher menu. I have edited several of these to my own requirements (hiding some applications, changing the names of some. etc). This all works fine until I carry out an update, when new versions of packages overwrite these modified files. I then have to do the modifications all over again. Very time-consuming and VERY annoying.
Does anyone have any ideas on how I can prevent this from happening?

I don't know how to prevent this from happening, but how to prevent you from having to do all the modifications all over again: It's actually that simple, I can't believe nobody suggested it, yet^^
Backup the modified .desktops in .backup or whereever you want them and after an upgrade, simply

cp .backup/*.desktop /usr/share/applications

myrlin · 2012-02-11 10:33:02

Very many thanks to everyone for all your advice.

@lucke: This looks like a great solution. I tried it on a single package, and, although I got some warnings from pacman, it didn't error out, so maybe it will be OK. I'll try it with a "pacman -Syu". If it works, it will mean that the upgrade process continues to be automatic, without need for further manual intervention, which is my aim
@swanson: Thank you for this script, and your help.
@desm0tes: This is so elegant:) Many thanks.

One (or several) of the suggestions you have all so kindly provided will deal with the problem, so I will mark this thread as "Solved".

Once again, thank you to everyone.

Awebb · 2012-02-11 10:52:29

How about an incron job, writing back your backups, whenever the files change?

lucke · 2012-02-11 10:52:32

I use that chattr trick for chromium.desktop - there should be no problems, only warnings when updating.

Arch Linux

#1 2012-02-09 15:42:43

[SOLVED] Protecting Desktop Files in /usr/share/applications

#2 2012-02-09 15:46:06

Re: [SOLVED] Protecting Desktop Files in /usr/share/applications

#3 2012-02-09 16:11:27

Re: [SOLVED] Protecting Desktop Files in /usr/share/applications

#4 2012-02-09 16:32:09

Re: [SOLVED] Protecting Desktop Files in /usr/share/applications

#5 2012-02-09 19:18:52

Re: [SOLVED] Protecting Desktop Files in /usr/share/applications

#6 2012-02-09 19:24:49

Re: [SOLVED] Protecting Desktop Files in /usr/share/applications

#7 2012-02-09 20:11:33

Re: [SOLVED] Protecting Desktop Files in /usr/share/applications

#8 2012-02-09 20:40:23

Re: [SOLVED] Protecting Desktop Files in /usr/share/applications

#9 2012-02-10 01:21:56

Re: [SOLVED] Protecting Desktop Files in /usr/share/applications

#10 2012-02-11 07:45:20

Re: [SOLVED] Protecting Desktop Files in /usr/share/applications

#11 2012-02-11 08:49:27

Re: [SOLVED] Protecting Desktop Files in /usr/share/applications

#12 2012-02-11 10:33:02

Re: [SOLVED] Protecting Desktop Files in /usr/share/applications

#13 2012-02-11 10:52:29

Re: [SOLVED] Protecting Desktop Files in /usr/share/applications

#14 2012-02-11 10:52:32

Re: [SOLVED] Protecting Desktop Files in /usr/share/applications

Board footer