[arch-general] The Final Cleanup

Gaetan Bisson bisson at archlinux.org
Fri Dec 6 12:54:35 EST 2013

[2013-12-06 18:15:36 +0100] Alexander Rødseth:
> I think .desktop files should ideally be provided by upstream. But for
> cases where they are not currently being provided, we should provide
> them.

Sure. That's exactly like service files, or rc.d files before that.
Nothing new here.

> Regardless of if it is correct that upstream should provide the
> .desktop files or not, the current plan is not working. TUs and devs
> are slow at reporting this as bugs and upstream are slow at
> responding. At the current rate, this will take years, perhaps
> decades. The current plan is not working.

Why not?

If a given package does not have a desktop file and nobody is bothered
enough to write one up and submit it through our bug tracker, then that
package does not really need a desktop file.

> Here are the arguments for generating the .desktop files with a tool
> like "gendesk":
> * There is much duplication of code by having one .desktop file per
> (GUI) package
> * If the .desktop specification should change in the future, there is
> only one tool that has to be changed, not bazillions of little
> .desktop files
> * If there should be alternative ways of providing desktop shortcuts
> in the future, possibly for other desktop environments, the transition
> will be easier
> * It's more elegant than including manually crafted files everywhere
> * It provides one consistent look of .desktop files and avoids
> problems (for instance, one hand crafted (or upstream provided?)
> .desktop file used Terminal=1 instead of Terminal=true, which caused
> problems). Generated files are consistent, which avoids problems.
> * gendesk is already being used for several packages (and has been
> used for a while), and it seems to work fine
> * Many files are generating during the prepare or build process.
> .desktop files should be generated too.

So you suggest we use pacman hooks to deal with desktop files?

Should service files be autogenerated as well?

(I don't think so.)

> If there are no protests, I will, after some time (say, three days
> without any replies to this thread):
> * Create a TODO for this
> * Start fixing the packages (I will not fix the packages of
> maintainers that wish to reserve themselves from this, of course).

I object to any mass automated update of our PKGBUILDs.

Why are you making such a big deal out of such an insignificant issue?
Packages for whom nobody has yet bothered to write a desktop file just
have no need for one...


More information about the arch-general mailing list