/cc @lethalman @vcunat @ttuegel Changed make-desktopitem in the past

@GrahamcOfBorg eval

Is there any particular reason why we are creating the .desktop file under share/applications instead of just in the root of the derivation? The .desktop are always copied into place later as well as processed again later to fix up paths so there isn't much point in having to dig it out from a directory structure several directories deep.

@peterhoeg I don't know what the reason for that decision was originally, but I agree that putting it in the root would make more sense.

Unfortunately, that would be a breaking change.

Doing grep makeDesktopItem -R pkgs -l - | wc -l on master right now reveals that this function is used in 95 files. All of these occurrences would have to be updated to pull from the new location, but I don't think that sounds like too much work.

Would it make sense to change that in this PR since this PR will cause a rebuild anyway, or would it be better to have such a change in a different PR, since it really is a different sort of change?

I think it makes sense to do it in 2 different PRs but then simply merge them at the same time. sed should be able to handle 95% of the changes.

I think it makes sense to do it in 2 different PRs but then simply merge them at the same time.

Would the second branch be based on master or on this branch?

If master, then there will be merge conflicts in pkgs/build-support/make-desktopitem/default.nix once this PR is merged.

If this branch, then the diff is going to be a bit deceiving until this PR goes through. Also, this branch is so old that we probably can't change all those files and expect to merge back into master without conflict.

My preference: merge this PR and then make a new branch off master to make the ${out}/share/applications -> ${out} change.

My preference: merge this PR and then make a new branch off master to make the ${out}/share/applications -> ${out} change.

I tend to agree with this; the changes are orthogonal and can live fine independently from each-other. (Abstracting away the wish to not incurr two rebuilds)

Additionally, some makeDesktopItem calls could drop their (redundant) genericName in the future (e.g. zsnes).

I have verified a couple of the affected derivations (some I expected a short build time for), and all work as-is. Tried removing a genericName and it built as expected.