Re: [arch-dev-public] [arch-general] The Final Cleanup
On 7 December 2013 01:15, Alexander Rødseth <rodseth@gmail.com> wrote:
If there are no protests, I will, after some time (say, three days
I don't think that's enough time to get the representative opinion. Anyway, on topic, I know I have at least a couple of packages where I provide the desktop file, but don't know if upstream presently includes one in their sources. I will have to attend to these. So, I say +1 to include desktop files as long as upstream does not provide them. You can file a bug report with them, but the desktop file stays until they attend to it. Also, it doesn't matter how it was created, as long as the package includes it. If a packager wants to go out of her way to provide a desktop file for software that traditionally do not ship with one, I say we allow her to do it. -- GPG/PGP ID: C0711BF1
Hi, 2013/12/6 Rashif Ray Rahman <schiv@archlinux.org>:
On 7 December 2013 01:15, Alexander Rødseth <rodseth@gmail.com> wrote:
If there are no protests, I will, after some time (say, three days
I don't think that's enough time to get the representative opinion.
You cut away the important part of the quote. Here is what I wrote: "three days without any replies to this thread" That means that after the last person has replied (there may be replies for days and weeks), I will wait three days. Do you think I should wait even longer after the last reply?
Anyway, on topic, I know I have at least a couple of packages where I provide the desktop file, but don't know if upstream presently includes one in their sources. I will have to attend to these.
Good point! Where upstream desktop files are available, that is preferable, of course.
So, I say +1 to include desktop files as long as upstream does not provide them. You can file a bug report with them, but the desktop file stays until they attend to it. Also, it doesn't matter how it was created, as long as the package includes it.
I disagree, I think all .desktop files should be removed from our repositories, with the only exception being if a package maintainer wishes to keep his packages like they are right now.
If a packager wants to go out of her way to provide a desktop file for software that traditionally do not ship with one, I say we allow her to do it.
I say we make it a requirement to provide one, for all GUI applications, but not by putting easily generated .desktop files into our repos. Do you know of any female Arch Linux package maintainers? I don't. - Alexander / xyproto
[2013-12-06 21:33:26 +0100] Alexander Rødseth:
I disagree, I think all .desktop files should be removed from our repositories, with the only exception being if a package maintainer wishes to keep his packages like they are right now.
It's quite patronizing for you to assume that the silent majority is on your side. Actually, I'll take it on mine: I will revert all the changes you make to packages of which the maintainers have not explicitly given their consent to your actions in this thread. Except of course if those maintainers explicitly contact me to opt out of the revert. -- Gaetan
On 7 December 2013 04:33, Alexander Rødseth <rodseth@gmail.com> wrote:
Hi,
2013/12/6 Rashif Ray Rahman <schiv@archlinux.org>:
On 7 December 2013 01:15, Alexander Rødseth <rodseth@gmail.com> wrote:
If there are no protests, I will, after some time (say, three days
I don't think that's enough time to get the representative opinion.
You cut away the important part of the quote. Here is what I wrote: "three days without any replies to this thread"
That means that after the last person has replied (there may be replies for days and weeks), I will wait three days. Do you think I should wait even longer after the last reply?
That's not a big problem -- and it might work well for trivial issues -- but I think a fixed time frame is always good due to the inherent uncertainty (the last reply could come now, or it could come next month).
If a packager wants to go out of her way to provide a desktop file for software that traditionally do not ship with one, I say we allow her to do it.
I say we make it a requirement to provide one, for all GUI applications, but not by putting easily generated .desktop files into our repos.
I'll refrain from reiterating my points since the discussion appears to be over.
Do you know of any female Arch Linux package maintainers? I don't.
So, off-topic: In an attempt to be gender-neutral I sometimes end up using alternative pronouns (which can be pointless, but you'll find more folks guilty of this than just me). Btw, we _did_ have one or two in the past, and we _could_ have another. You never know. -- GPG/PGP ID: C0711BF1
[2013-12-06 21:33:26 +0100] Alexander Rødseth:
not by putting easily generated .desktop files into our repos.
I was not sure how gendesk worked, but I just happened to look at: https://projects.archlinux.org/svntogit/community.git/commit/trunk?h=package... It seems gendesk requires as argument most of what used to be the content of the desktop file itself. So I fail to see the gain, because: - those arguments are not much shorter than the desktop file itself - this relies on a tool to do what can be done just as easily by hand - this adds more complexity to the prepare() function - this adds an extra makedepends Static desktop files appear to be a much better option. -- Gaetan
Hi Gaetan, Normally, only --pkgname and --pkgdesc are needed. The sage-mathematics PKGBUILD is an extreme example. Compare with other PKGBUILDs that uses gendesk for a more balanced picture. Thanks for the new arguments, though, I added them to the list of arguments for/against gendesk: 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. * "I've just tried gendesk and it's pretty neat actually." * Removes complexity from the package, since fewer files are needed. Here are the arguments against generating the .desktop files with a tool like "gendesk": * It is just like including base64 encoded files directly in the PKGBUILD. (No, it's not. Contrast with other build-time generated files) * Current .desktop files should be left as they are. * Generating the .desktop files does not make the packages more "vanilla". (.desktop files are inherently non-vanilla, though). * It takes a bit of work to create a package in the first place. Adding a .desktop file or not won't make a difference in the overall burden. * The functionality should rather be in makepkg.. * The maintainer still needs to relate to .desktop files one way or the other. * Using gendesk relies on a tool to do what can be done just as easily by hand. * This adds more complexity to the prepare() function. * This adds an extra makedepends (Only a small build-time dependency, though. Most users will never see this). - Alexander / xyproto
On 09/12/13 20:52, Alexander Rødseth wrote:
Here are the arguments for generating the .desktop files with a tool like "gendesk":
<snip>
Here are the arguments against generating the .desktop files with a tool like "gendesk":
<snip> Long list... which has no effect on our users provided that .desktop files are in the packages that require them. So I think the decision of how to handle them should be down to the packages. Allan
participants (4)
-
Alexander Rødseth
-
Allan McRae
-
Gaetan Bisson
-
Rashif Ray Rahman