On 7 December 2013 04:33, Alexander Rødseth wrote:

Hi,

2013/12/6 Rashif Ray Rahman :

...

On 7 December 2013 01:15, Alexander Rødseth 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

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