Hi, I am packaging the application tnef [1], where the reviewer has queried whether I need to provide a desktop file.
This is a little different from a normal GUI application desktop file. The application is command line only. I have added a shellscript, and some desktop files that cause nautilus and kde file managers to show .dat files as having a potential open with tnef extract entry.
So while I'm including .desktop files, they aren't in the menus. Is this acceptable, packaging wise ?
David. [1] https://bugzilla.redhat.com/show_bug.cgi?id=522920
On Saturday 20 March 2010, David Timms wrote:
Hi, I am packaging the application tnef [1], where the reviewer has queried whether I need to provide a desktop file.
This is a little different from a normal GUI application desktop file. The application is command line only. I have added a shellscript, and some desktop files that cause nautilus and kde file managers to show .dat files as having a potential open with tnef extract entry.
So while I'm including .desktop files, they aren't in the menus. Is this acceptable, packaging wise ?
Sure, if there's nothing to put in menus that would be useful without a filename (or other non-static) argument.
Dear fellows. I would like to ask you for guidance what should be the best way to resolve the collision in versioning scheme introduced in the upstream nikto package.
I am trying to submit package update to the fedora https://bugzilla.redhat.com/show_bug.cgi?id=575605
Versioning scheme for nikto was sofar: 2.01, 2.02, 2.03 The new nikto release version is 2.1.1 . Version 2.1.1 is numerically lower than 2.03, which is currently present in the distribution.
Please could you give me some hints what is the best approach how to deal with this verison scheme change?
Rename the package to something like nikto2 with new versioning scheme? Is there some other way?
Thank you Michal Ambroz
On Sun, Mar 21, 2010 at 19:32:36 +0100, Michal Ambroz rebus@seznam.cz wrote:
Versioning scheme for nikto was sofar: 2.01, 2.02, 2.03 The new nikto release version is 2.1.1 . Version 2.1.1 is numerically lower than 2.03, which is currently present in the distribution.
Please could you give me some hints what is the best approach how to deal with this verison scheme change?
I would think that bumping the epoch is probably the right thing to do.
On 2010-03-22 03:07:30，"Bruno Wolff III" bruno@wolff.to wrote：
I would think that bumping the epoch is probably the right thing to do.
+1, debian guys already bump epoch for this package.
Michal Ambroz wrote, On 03/21/2010 07:32 PM:
Dear fellows. I would like to ask you for guidance what should be the best way to resolve the collision in versioning scheme introduced in the upstream nikto package.
I am trying to submit package update to the fedora https://bugzilla.redhat.com/show_bug.cgi?id=575605
So you are not the Fedora nikto packager? It is the packagers job to update the package. He might appreciate your help, but you should contact him and not file a review request. This looks like an unfortunate and probably unintended attempt at hijacking the package.
Versioning scheme for nikto was sofar: 2.01, 2.02, 2.03 The new nikto release version is 2.1.1 . Version 2.1.1 is numerically lower than 2.03, which is currently present in the distribution.
Please could you give me some hints what is the best approach how to deal with this verison scheme change?
Rename the package to something like nikto2 with new versioning scheme? Is there some other way?
(As Bruno said: http://fedoraproject.org/wiki/PackagingGuidelines#Use_of_Epochs .)
It seems like a wise decision upstream to change their versioning scheme, but perhaps they should be suggested to bump it to something less ambiguous - for example 2.3.1.
/Mads
On 03/20/2010 06:14 AM, Ville Skyttä wrote:
On Saturday 20 March 2010, David Timms wrote:
Hi, I am packaging the application tnef [1], where the reviewer has queried whether I need to provide a desktop file.
This is a little different from a normal GUI application desktop file. The application is command line only. I have added a shellscript, and some desktop files that cause nautilus and kde file managers to show .dat files as having a potential open with tnef extract entry.
So while I'm including .desktop files, they aren't in the menus. Is this acceptable, packaging wise ?
Sure, if there's nothing to put in menus that would be useful without a filename (or other non-static) argument.
From: https://fedoraproject.org/wiki/Packaging/Guidelines#Desktop_files
If a package contains a GUI application, then it needs to also include a properly installed .desktop file. For the purposes of these guidelines, a GUI application is defined as any application which draws an X window and runs from within that window.
Does the tnef application meet that criteria?
~spot
On Mon, 2010-03-22 at 09:10 -0400, Tom "spot" Callaway wrote:
On 03/20/2010 06:14 AM, Ville Skyttä wrote:
On Saturday 20 March 2010, David Timms wrote:
Hi, I am packaging the application tnef [1], where the reviewer has queried whether I need to provide a desktop file.
This is a little different from a normal GUI application desktop file. The application is command line only. I have added a shellscript, and some desktop files that cause nautilus and kde file managers to show .dat files as having a potential open with tnef extract entry.
So while I'm including .desktop files, they aren't in the menus. Is this acceptable, packaging wise ?
Sure, if there's nothing to put in menus that would be useful without a filename (or other non-static) argument.
From: https://fedoraproject.org/wiki/Packaging/Guidelines#Desktop_files
If a package contains a GUI application, then it needs to also include a properly installed .desktop file. For the purposes of these guidelines, a GUI application is defined as any application which draws an X window and runs from within that window.
Does the tnef application meet that criteria?
That's inverse logic though because he's including a .desktop file in a case where he doesn't have to. I don't see any justification for saying one can't ship one if one wants to.
Jon.
On 03/22/2010 03:07 PM, Jon Masters wrote:
That's inverse logic though because he's including a .desktop file in a case where he doesn't have to. I don't see any justification for saying one can't ship one if one wants to.
Yeah, so I have no problem with a packager including desktop files for proper nautilus integration in situations where the application would not otherwise require it.
~spot
On 23/03/10 06:07, Jon Masters wrote:
On Mon, 2010-03-22 at 09:10 -0400, Tom "spot" Callaway wrote:
...
If a package contains a GUI application, then it needs to also include a properly installed .desktop file. For the purposes of these guidelines, a GUI application is defined as any application which draws an X window and runs from within that window.
Does the tnef application meet that criteria?
No.
I think we might be looking at the inversion of that item, ie if it isn't a gui app, is it allowed to have desktop files ?
ie:
That's inverse logic though because he's including a .desktop file in a case where he doesn't have to. I don't see any justification for saying one can't ship one if one wants to.
Are there any existing cases like this that we could examine ?
David.
On 03/22/2010 04:24 PM, David Timms wrote:
I think we might be looking at the inversion of that item, ie if it isn't a gui app, is it allowed to have desktop files ?
I think it is fine for him to do that, especially given that these files are only being used by the desktop browsers (e.g. nautilus and kde file managers) and don't add noise to the desktop menus.
~spot
On 03/22/2010 05:08 PM, Tom "spot" Callaway wrote:
On 03/22/2010 04:24 PM, David Timms wrote:
I think we might be looking at the inversion of that item, ie if it isn't a gui app, is it allowed to have desktop files ?
I think it is fine for him to do that, especially given that these files are only being used by the desktop browsers (e.g. nautilus and kde file managers) and don't add noise to the desktop menus.
And by him, I mean you. :) Or anyone. :)
~spot
packaging@lists.fedoraproject.org
-
Bruno Wolff III -
Chen Lei -
Development discussions related to Fedora -
Jon Masters -
Mads Kiilerich -
Michal Ambroz -
Tom Callaway -
Ville Skyttä