Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#23387 - [community] Cleanup of .desktop files

Attached to Project: Community Packages
Opened by Thomas Dziedzic (tomd123) - Tuesday, 22 March 2011, 17:44 GMT
Last edited by Alexander F Rødseth (xyproto) (trontonic) - Sunday, 08 December 2013, 10:43 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Sergej Pupykin (sergej)
Jaroslav Lichtblau (Dragonlord)
Jonathan Steel (jsteel)
Sven-Hendrik Haase (Svenstaro)
Lukas Fleischer (lfleischer)
Kyle Keen (keenerd)
Laurent Carlier (lordheavy)
Maxime Gauduin (Alucryd)
Architecture All
Severity Low
Priority Low
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 7
Private No


Since archlinux advertises itself as having vanilla packages, I thought it might be a good idea to contact upstream about including these desktop files in their sources.
Packages should only be moved to the Done list if the .desktop files are removed from svn repos and the package itself.
In case upstream does reject taking in the .desktop file, put it in the Done (rejected) list but do not delete the .desktop files from the package.

Relevant quote:
"Patching only occurs in extremely rare cases, to prevent severe breakage in the instance of version mismatches that may occur within a rolling release model." -

find /var/abs/community -name '*.desktop' | sort -u | wc -l

Not Done:

Pending (have been reported):
blobby2/blobby2.desktop (
bomberclone/bomberclone.desktop (
caph/caph.desktop (
checkgmail/checkgmail.desktop (
gcolor2/gcolor2.desktop -
higan-gtk/purify.desktop (using gendesk for now, will contact upstream to have it included)
higan-qt/purify.desktop (using gendesk for now, will contact upstream to have it included)
pingus/pingus.desktop -
rbutil/rbutil.desktop (
speed-dreams/speed-dreams.desktop (
tea/tea.desktop - sent to author, he promised to include in next release
tremulous/tremulous.desktop -
umlet/umlet.desktop - sent to upstream -
uqm/uqm.desktop -

Done (upstream has a .desktop file):
alienarena/alienarena.desktop (
higan-gtk/higan.desktop (upstream desktop is there, but I prefer gendesk for the custom wrapper I have bundled)
higan-qt/higan.desktop (upstream desktop is there, but I prefer gendesk for the custom wrapper I have bundled)
jedit/jedit.desktop (
netbeans/netbeans.desktop -
openarena/openarena.desktop (has official desktop, but now in AUR)
sxiv/sxiv.desktop (
torcs/torcs.desktop (
qmc2/qmamecat.desktop - also improved version sent to ML
root/root.desktop -
spyder/spyder.desktop -
vdrift/vdrift.desktop (it's in, waiting for new release)
xmonad/xmonad.desktop (

Done (rejected the .desktop file):
gens/gens.desktop (switched to gendesk, no release in 5 years, pretty much dead)
nexuiz/nexuiz-glx.desktop (nexuiz is effectively dead)
nexuiz/nexuiz-sdl.desktop (nexuiz is effectively dead)
qgit/qgit.desktop (no project activity in 3 yrs)
intellij-idea-community-edition/intellijidea.desktop - IDEA has an option to generate desktop file from GUI, so there's no stand-alone file provided:
This task depends upon

Closed by  Alexander F Rødseth (xyproto) (trontonic)
Sunday, 08 December 2013, 10:43 GMT
Reason for closing:  Won't fix
Comment by Ike Devolder (BlackEagle) - Tuesday, 22 March 2011, 21:42 GMT
sorry but in my opinion, this is not patching, this is improving the user experience

now you would suggest to the users, keep your own .desktop files around somewhere because we will be dropping them as soon as possible
Comment by Thomas Dziedzic (tomd123) - Tuesday, 22 March 2011, 23:57 GMT
I guess the right thing to do here, is to instead keep a list of packages we know we will be dropping .desktop files for and in the end, warn users.

I would count the .desktop files as patching the package in a conceptual way.
Therefore, I think .desktop files have no place in our repos.
Comment by Allan McRae (Allan) - Wednesday, 23 March 2011, 22:26 GMT
Just as an FYI... Go back a couple of years and you will find a Arch project that was set-up to provide these .desktop files and try getting them included upstream.
Comment by Thomas Dziedzic (tomd123) - Sunday, 27 March 2011, 04:37 GMT
After some discussion, I would like to make it clear that instead of deleting the .desktops, they will stay if upstream refuses.
Comment by Thomas Dziedzic (tomd123) - Sunday, 27 March 2011, 15:24 GMT
To the TUs, please remove yourself if none of your packages are on the TODO list
Comment by Andrea Scarpino (BaSh) - Sunday, 27 March 2011, 15:29 GMT Comment by Thomas Dziedzic (tomd123) - Monday, 28 March 2011, 17:08 GMT
I think we should just keep using this BR since I already created it.

Also from
"A package which does not include a .desktop file or icons or other freedesktop stuff. This is not a bug if such files are not included in the source tarball, and this must be requested as a feature request upstream. If such files are provided by upstream but not used in the package then this is a bug."
Comment by Stefan Husmann (stefanhusmann) - Tuesday, 29 March 2011, 10:14 GMT
multiget: Done, Upstream has an desktop file in svn (not in tarball, but that one does not build anyway).
xskat: Asked upstream. They do not consider it necessary to integrate the desktop file, but they have nothing against having one.
Comment by Brad Fanella (itsbrad212) - Tuesday, 29 March 2011, 19:15 GMT
Remember to edit the task and move your packages to the corresponding section when you're done. :-)
Comment by Greg (dolby) - Friday, 01 April 2011, 23:48 GMT
Noble cause but you're not gonna like the results. This is gonna get nasty eventually and you're gonna settle with including the desktop files in the end. Good luck trying to convince upstreams like dwm (and many others) to include them. IIRC the previous attempt didnt produce much either.
That being said you have 100% my support with this.
BTW if you mean to have a vanilla Arch you should start at the top of the pyramid, the Linux kernel...
In general dealing with the patched sources is better spent time than dealing with the desktop files IMO.

edit: oh, you said above you're gonna keep them even if rejected.
Comment by Thomas Dziedzic (tomd123) - Tuesday, 10 May 2011, 23:54 GMT
going to close this BR since I see not a lot of people are interested in seeing this getting fixed
Comment by Sven-Hendrik Haase (Svenstaro) - Wednesday, 11 May 2011, 00:29 GMT
I think you should keep it open. It is a slow and tedious process but in the long run all projects involved will benefit. I, for one, sent out a few notices to some projects and will keep doing that for my packages.
Comment by Stefan Husmann (stefanhusmann) - Thursday, 12 May 2011, 17:15 GMT
Yes, please keep it open. Cannot find better words than Sven-Hendrik for the reasons.
Comment by Jakob Matthes (jakobm) - Wednesday, 07 September 2011, 11:07 GMT
Here is some progress on this issue:
I do not know if a wiki page is convenient for you, I simply needed to take notes/keep track of the packages.
Comment by Alexander F Rødseth (xyproto) (trontonic) - Wednesday, 14 March 2012, 09:34 GMT
How about having a package that installs all custom-made .desktop files into /usr/share/desktop-files, then packages can depend on that package and copy the right .desktop file in place.
That way .desktop files aren't included with packages for projects that miss .desktop file and the "desktop-files" package can be its own project (where upstream can go look for .desktop files, if they want).
I hereby volunteer to gather all the tiny .desktop files into a tarball and create the "desktop-files" package.
What say you?
Comment by Lukas Jirkovsky (6xx) - Wednesday, 14 March 2012, 10:46 GMT
I really, really doesn't like that. Having tons of unused desktop files is not what I want to have on my desktop. Not to mention that it would have to be updated everytime some of the desktop files change (even when the user doesn't have that particular app installed).

Also, I feel having such separate project would move the interest to upstream the desktop files from individiuals. What I mean by this is that everytime I build a package, I see there's a desktop file which should be moved to upstream. I didn't see it, I wouldn't think of that file at all.
Comment by Alexander F Rødseth (xyproto) (trontonic) - Wednesday, 14 March 2012, 13:59 GMT
Ok, how about a .desktop file generator, then? For most GUI apps this can be done, including creating icons based on images from web.
Comment by Lukas Jirkovsky (6xx) - Wednesday, 14 March 2012, 14:12 GMT
While the generator may work, it still doesn't fix the real issue which is using desktop files that are not available upstream.
Comment by Alexander F Rødseth (xyproto) (trontonic) - Wednesday, 14 March 2012, 22:58 GMT
If .desktop files are generated, it would be comparable to how executables are generated from source. It is not normally viewed as an issue if upstream only provides source code and not executables.
Comment by Lukas Jirkovsky (6xx) - Saturday, 17 March 2012, 16:33 GMT
I'm still not convinced this is way to go. When you build a package from sources you usually use some kind of buildsystem provided upstream. I may be wrong but the generator thing looks like "let's download some stuff from the internet randomly and generate a desktop file from that"
Comment by Alexander F Rødseth (xyproto) (trontonic) - Saturday, 17 March 2012, 17:05 GMT
I'll see if I can find time make a proof of concept :)
Comment by Alexander F Rødseth (xyproto) (trontonic) - Sunday, 18 March 2012, 20:02 GMT
Also, Lukas, we're eagerly awaiting your ideas, to see if they are to our liking and if you can convince us. Bring it on.
Comment by Lukas Jirkovsky (6xx) - Sunday, 18 March 2012, 20:48 GMT
Alexander: sure. Of course, the best solution is to push the desktop files upstream. If it's not possible for some reason (dead upstream, upstream rejected it) I'm in favor of providing our own desktop files as we do now.

I don't see what makes using some generator any better than providing "hand-made" desktop file. If the generated files should be of a reasonable quality, we will still have to give the generator some suggestions. In that case it would become only a more readable version of 'echo "[Desktop Entry]" > app.desktop; echo "Type=Application" >> app.desktop…' in a PKGBUILD.

I don't see removing the desktop files altogether as its suggested in the bug report to be a solution either. In my opinion this would be against our beloved KISS philosophy. We would unnecessarily force users to create their own desktop files. This would most likely result in a lot of duplication (everyone would use their own desktop file), lots of angry users ("Why did the icon disappeared?!") and probably some crap in a file system too (since the users would have to remove a desktop file themselves when they it's no longer useful while now it's removed when the package is removed).
Comment by Alexander F Rødseth (xyproto) (trontonic) - Tuesday, 20 March 2012, 17:47 GMT
Okay, here's my proof of concept, a small utility named "gendesk":

It reads from a PKGBUILD and writes to a .desktop and .png file, in the current directory. Note that it will overwrite any $pkgname.desktop and $pkgname.png files already present, so be careful.

Icons are downloaded from fedoraproject, but this could easly be replaced or supplemented by other icon-providing web resources in the future.

It's not perfect, and it's version 0.1, but it should work pretty well for several applications where upstream currently does not provide a .desktop file and icon.

Test it on the maniadrive PKGBUILD, for example:

Comment by Alexander F Rødseth (xyproto) (trontonic) - Wednesday, 28 March 2012, 16:48 GMT

I have started removing .desktop files and replacing them with generated ones, while checking that the result is very close to the original and making sure the package still builds.

Please contribute patches to "gendesk", here's the project page:

If icons are already checked in, no icon is downloaded. If PKGBUILD files download icons in the source array, no icon is downloaded.
If there's no icon available from the icon web service, an icon with a picture of Rainbow Dash is used, as an incentive for upstream developers to create one.

If I indadvertently have or will change a package you own in a way that is not to your tastes, in the process of removing .desktop files, then I'm sorry in advance.
Luckily, if that should be the case, it should be easy to fix (and it was for the greater good). :)

To remove .desktop files and use generated ones, a simple method that often will work without further modification is to:

* Add gendesk to makedepends

* Start the build() function with:
cd "$srcdir"
# And then the rest

* Make sure the .png and .desktop file is actually installed in the package() function

Please help out in removing .desktop files and replacing them with generated ones.
Alternatively, try finding The Perfect Solution (tm) for closing this ticket, for another 372 days. ;)
Comment by Lukas Jirkovsky (6xx) - Thursday, 29 March 2012, 13:32 GMT
Alexander: I've just tried gendesk and it's pretty neat actually.

However, I'm strongly against to just replacing the manually created files with the generated ones. What I'd love to see is to either have gendesk functionality in makepkg or use it as a makedepend and utilize it in the package() function to generate a desktop file. Maybe you already do that, I just can't find any package where you've used gendesk.

PS.: Please do not replace the desktop file in my intellij-idea package, because the generated one isn't very good.
Comment by Alexander F Rødseth (xyproto) (trontonic) - Saturday, 31 March 2012, 20:41 GMT
Glad you found gendesk neat. If the functionality could be included in makepkg somehow, that would be great.

Running gendesk from build() instead of package() seems more intuitive to me, since gendesk _creates_ files (usually reserved for the build() function), while package() usually doesn't create files, just package them.
Note that gendesk supports split packages, even if run from the build() function.

I disagree with your sentiment that the generated .desktop files aren't very good, as they can be customized with the _name=(), _exec=() and _comment=() variables (amongst others) in the PKGBUILD.
This makes the resulting .desktop files look almost exactly like the ones they are replacing.

Case in point, here's an updated PKGBUILD for your intellij-idea package that generates a (IMO) perfectly fine .desktop file:
* Old PKGBUILD, for comparison:
* New generated desktop file:
* Old checked in desktop file, for comparison:

I would say this is good enough to remove all .desktop files from our repository.
Comment by Bartłomiej Piotrowski (Barthalion) - Sunday, 01 April 2012, 15:02 GMT
While gendesk works fine, I'm not really convinced to use it as replacement of separated .desktop file. It's less clean than including hand-made file for me and I'm generally against of using it. As Ike wrote in the first comment, it's rather improving user experience than applying heavy patches.
Comment by Alexander F Rødseth (xyproto) (trontonic) - Sunday, 01 April 2012, 20:49 GMT
The very best solution is obviously if upstream starts including desktop files and icons.

Improving the user experience for an upstream application should be done by upstream, just like patching an application should be done by upstream.
However, patches are some times applied temporarily, while waiting for upstream. This is a similar situation.

As a stop-gap measure, I think gendesk is an ok solution, at least good enough to remove .desktop files from our repository.
Comment by Bartłomiej Piotrowski (Barthalion) - Monday, 02 April 2012, 17:59 GMT
This is still using external app to do the same job as maintainter did once to create .desktop file. Using it is fine, if you think that gendesk is solution, but I don't get it; it's the same problem with different name.
Comment by Sébastien Luttringer (seblu) - Monday, 02 April 2012, 18:09 GMT
Alexander i see you updated desktop file in next comming awesome package. 3 questions:

- Why not let maintainers take your soft in hand and choose if they prefer use it or let a manual desktop file?

- Generated desktop file for awesome is different that the orginial one adding some information:

Icon=awesome.png => file not existant
StartupNotify=false => Not revelent it's a Windows manager
Terminal=false => idem
Categories=Application; => idem

All those line are "bad" for a windows manager desktop file. I'm wondering if using generator is a good idea. Do you think?

- Why generate temporary desktop file inside directory containing PKGBUILD instead of running directory.
cd "$srcdir"
setconf "$pkgname.desktop" Type XSession

I see issues coming if $startdir is not writable. I would test it in my chroot but my ... openvpn is down.
Comment by Alexander F Rødseth (xyproto) (trontonic) - Monday, 02 April 2012, 20:49 GMT

I gave this a second thought while walking home today. This perhaps isn't really "The Arch Way", and I agree that using gendesk doesn't really make that much of a difference except literally getting rid of the .desktop files.

One potential advantage of using gendesk is that variables like Exec are set directly in the PKGBUILD. This may be subjective, but I feel like it belongs there, together with pkgname and pkgdesc.
Also, if one day the .desktop spec should change, all generated files can be updated in one go. But, these are minor advantages, I guess.

If the current situation with .desktop files isn't too shabby after all, how about we just close this bug with "Won't fix"?
Comment by Lukas Jirkovsky (6xx) - Tuesday, 03 April 2012, 10:10 GMT
I think that gendesk is a useful tool. I don't mean it should be mandatory to use it, but I find writing own desktop files to be rather tedious. Especially in my AUR packages I usually add a desktop file only after someone asks for it or if I find it useful myself.

As for closing this bug: I always thought that this bug would be annoying enough to force TUs to try to push desktop files upstream. However, given the long list "Not Done" it doesn't seem to do so. It spooks our bug tracker for quite some time without having much attention, so I don't have any feelings either way.
Comment by Alexander F Rødseth (xyproto) (trontonic) - Tuesday, 03 April 2012, 11:17 GMT
@seblu, awesome.png does exists (/usr/share/pixmaps/awesome.png was present when I looked right now). Which revision of the awesome PKGBUILD are you looking at, exactly?
Non-relevant fields like "StartupNotify=false" and "Terminal=false" does no harm, but they can be removed in future versions of gendesk. Patches are welcome.
Desktop files _are_ generated in running directory and you can specify the path to a PKGBUILD as a first parameter.
If you test it in your chroot I think you will find that those parts work fine. However, it seems to have problems with cmake and cairo-xcb when I tried to build it right now.
Comment by Sébastien Luttringer (seblu) - Tuesday, 03 April 2012, 12:15 GMT
when i look inside awesome.png i see a pony :). That's what i call file not exist.

gendesk PKGBUILD
[awesome] Generating desktop file... ok
[awesome] Downloading icon... no
[awesome] Using default icon instead... yes

About patches, its question of time. Using your tool to generate a .desktop is useful. But vim can do the last fixes and let me sure that upgrade of your program doesn't introduce unexpected change in the desktop file between awesome (or others) updates.

I'm not completly sure that's have a generator (call each build) for this kind a file is something will help me to improve my day to day works on packages or improve user experience. But using it to create original desktop file, that's great.
That's why i suggest you to let maintainer choose if they want use it or not.

About local generation, you're right. I was tricked by the remaining awesome.desktop symlink in $src which let gendesk create file in $startdir. As a side note, i see, some time, downloading of icon fail (probably poor network), and let a bad icon take place.
Comment by Alexander F Rødseth (xyproto) (trontonic) - Tuesday, 03 April 2012, 14:39 GMT
@6xx What are you thoughts on either a bug request per package, for submitting the .desktop file upstream? (and/or nagging upstream about it), or a TODO?

This is now our oldest [community] ticket that is still open, btw. :) (I started closing old bugs, which is why I stumbled over this one).
Comment by Lukas Jirkovsky (6xx) - Wednesday, 04 April 2012, 15:45 GMT
trontonic: TODO makes more sense to me, since it's not a bug, but a thing that should be done. However I'm not sure whether TODO will lead anywhere (ie. it may be ignored the same way as this bug is), so we may as well close the bug and don't care about it anymore.
Comment by Alexander F Rødseth (xyproto) (trontonic) - Wednesday, 04 April 2012, 21:31 GMT
Allright, closing this one as "Not a bug". If anyone cares enough, a TODO is fully possible. :)

Thanks for reading.
Comment by Alexander F Rødseth (xyproto) (trontonic) - Tuesday, 10 April 2012, 22:04 GMT
@keenerd How about a TODO instead of reopening this one? Keeping this one open has not had any significant effect so far.

If it's reopened only because of rules, regulation and byrocracy, let me point out that this bug report has several technical problems since it:
- Does not include a version number (
- Does not indicate how to reproduce the bug (
- Does not start the summary with package name enclosed in square brackets (

If it's reopened for practical reasons, please inform us of the advantages of this bug report compared to creating a TODO list instead.
Comment by Kyle Keen (keenerd) - Tuesday, 10 April 2012, 23:24 GMT
Trontronic: If you have an ax to grind, take it someplace else. There are half a dozen devs/TUs who have vocally supported this in the comments, and a few like myself who have said nothing but work to fix up packages. You have spammed up half the comments here talking about an interesting but unrelated project. Some of us are actually trying to get this stuff merged upstream and we are making progress.

This was reopened because two more packages got fixed and I checked them off. Todo lists are for officially coordinated internal rebuilds (not for dealing with upstream or users) and can't be edited by just anyone. While a bug report is not optimal, it was previously decided that a single parent task would work better than a todo or opening a hundred individual bugs.

It may offend your militant sense of order, but this bug report is not hurting you. Un-assign yourself if you don't want the updates appearing in your mailbox. Let the rest of us get on with fixing it.
Comment by Alexander F Rødseth (xyproto) (trontonic) - Wednesday, 11 April 2012, 07:48 GMT
keenerd, stay on topic, stay cool, stay professional and don't make it into a discussion about me.
I disagree strongly that I "have an ax to grind", that I spam this bug report or that I have "a militant sense of order".
These claims are all off topic (and misguided).

I'm glad you agree that this bug report doesn't fit the intended purpose and I can agree that a TODO doesn't fit either. Closing as "Not a bug".
Comment by Jelle van der Waa (jelly) - Wednesday, 11 April 2012, 11:37 GMT
Please keep it open, since we have decided that this should be a task.
Comment by Lukas Jirkovsky (6xx) - Wednesday, 11 April 2012, 15:27 GMT
I'm convinced TODO is more appropriate. Also I think the TODO interface (Complete/Incomplete) is better suited for this task.
Comment by Chris Brannon (cmb) - Wednesday, 11 April 2012, 15:57 GMT
+1 from me.
I have flyspray configured to email me, and I get notified every time
someone does something to this bug report.
It's mildly obnoxious.
Comment by Alexander F Rødseth (xyproto) (trontonic) - Wednesday, 11 April 2012, 17:20 GMT
+1 from me too, but a wiki page would be even better, IMO.
However, "the we" (whomever they may be) have decided that this should be a task forever, so I guess there's nothing we can do... ಠ_ಠ
Comment by Chris Brannon (cmb) - Monday, 16 April 2012, 18:11 GMT
Moved mldonkey from not done to done.
The .desktop was added by upstream to mldonkey-3.1.1.
Comment by Alexander F Rødseth (xyproto) (trontonic) - Monday, 06 August 2012, 23:30 GMT
Added a wiki page that has an up-to-date overview of which packages include .desktop files:

Keeping information up-to-date is one of the things wiki pages are well suited for, as opposed to bug reports.

As this ticket hasn't seen much progress since it was reopened last time (with the current rate, it should be completed around 2039), and since there is now a wiki page that covers the same tasks and has a more managable overview, I sincerely hope that people are now okay with closing this one (which is also one of our two oldest community tickets).
Comment by Lukas Jirkovsky (6xx) - Thursday, 15 August 2013, 17:33 GMT
Why was this bug report reopened?

Anyway, I hope that the possibility of dropping all .desktop files is no longer considered (as mentioned previously). The desktop files don't pose any significant maintenance burden, nor they take a lot of space if the space was an issue.

Otherwise I fully support this effort. However it seems no one really cares given how long the "Not Done" list is.
Comment by Alexander F Rødseth (xyproto) (trontonic) - Thursday, 15 August 2013, 17:49 GMT
Updated the wiki page (the gendesk tool has been updated too):
Comment by György Balló (City-busz) - Monday, 09 September 2013, 02:33 GMT
This is our last task from 2011 on Flyspray for the community packages. I think it's time to close it now. The wiki page or a TODO list is a better place to organize this task.
Comment by Alexander F Rødseth (xyproto) (trontonic) - Monday, 09 September 2013, 09:42 GMT
How about a TODO?

(I am willing to put in some time and effort to fix several packages, as long as the current maintainers are fine with it).
Comment by Alexander F Rødseth (xyproto) (trontonic) - Friday, 06 December 2013, 14:43 GMT
Here is an updated list of packages that should probably not include a .desktop file, grouped by maintainer (or by last packager, for a few cases):

Angel Velasquez <angvp>:

Balló György <ballogyor>:

Eric Belanger <snowman>:

Evgeniy Alekseev <arcanis>:

Felix Yan <felixonmars>:

Florian Pritz <bluewind>:

Jan de Groot <JGC>:

Jaroslav Lichtblau <drag0nl0rd>:

Jonathan Steel <jsteel>:

Kyle Keen <keenerd>:

Laurent Carlier <lordheavy>:

Lukas Fleischer <cryptocrack>:

Lukas Jirkovsky <stativ>:

Maxime Gauduin <alucryd>:

Rashif Rahman (Ray) <schiv>:

Sergej Pupykin <sergej>:

Sven-Hendrik Haase <svenstaro>:

Sébastien Luttringer <seblu>:

Jakob Gruber <schuay>:

speps <speps>:

I am planning to start removing the .desktop files and replacing them with generated ones unless there are reservations from the above maintainers.

The gendesk tool now has a -wm flag for generating .desktop files that are suitable for launching window managers (can be used by kdm, for instance).
Comment by Eric Belanger (Snowman) - Friday, 06 December 2013, 19:47 GMT
Please don't touch the .desktop of my packages.
Comment by Alexander F Rødseth (xyproto) (trontonic) - Sunday, 08 December 2013, 10:43 GMT
Closing this bug after having discussed it at length at arch-general and arch-dev-public.

Significant quotes from Allan McRae:

"As far as I am concerned, if upstream does not provide one, it is up to
the packager whether to use gendesk or a handcrafted .desktop file."


"There is no need to do anything here apart from packages that do not
provide a .desktop file that should need one added."

So, if your package currently could need a .desktop file, feel free to provide one and/or contact upstream.

If you think upstream should be contacted for all the packages that could need a .desktop file provided by upstream, feel free to contact upstream, discuss it on the mailinglist, create a wiki page or a TODO for the purpose of contacting upstream.

If you wish to remove the .desktop file from your package sources and generate one instead, feel free to do so as well.

Closing this bug. Complaints can be sent to the mailinglist discussion.

Edit: For the record, I will not start removing .desktop files from the above packages, as was my original plan, due to the discussion on the mailinglist.