This just adds noise and cruft to desktop files and spec files. It is not used by anything.
Likewise --vendor fedora, but current desktop-file-install requires a vendor even though it isn't in use. We'll be fixing that shortly though.
So for now, can I get votes to remove the --add-category X-Fedora line from the guidelines?
For the --vendor thing, it should probably stay in for now for older releases since I don't want to see our guidelines get too broken up between what is allowed or disallowed per release.
Ville Skyttä wrote :
On Thu, 2006-10-26 at 10:47 -0400, Jesse Keating wrote:
So for now, can I get votes to remove the --add-category X-Fedora line from the guidelines?
+1
Always count me in when it's about removing useless stuff! :-)
Matthias
Jesse Keating wrote:
This just adds noise and cruft to desktop files and spec files. It is not used by anything.
Likewise --vendor fedora, but current desktop-file-install requires a vendor even though it isn't in use. We'll be fixing that shortly though.
--vendor is recommended by the menu spec, but I'm not sure it should be mandatory (I'm leaning toward no).
So for now, can I get votes to remove the --add-category X-Fedora line from the guidelines?
I don't see the facility in this either, +1.
-- Rex
"JK" == Jesse Keating jkeating@redhat.com writes:
JK> So for now, can I get votes to remove the --add-category X-Fedora JK> line from the guidelines?
Could we first understand why it was added in the first place? There must have been a reason, and knowing it should make it easy to decide whether or not it's still reasonable.
- J
On Thursday 26 October 2006 11:05, Jason L Tibbitts III wrote:
Could we first understand why it was added in the first place? There must have been a reason, and knowing it should make it easy to decide whether or not it's still reasonable.
The best I've heard so far was carryover from fedora.us...
"JK" == Jesse Keating jkeating@redhat.com writes:
JK> The best I've heard so far was carryover from fedora.us...
I guess that if nobody knows of any reason why it should be there, then it doesn't need to be there.
I'll +1 to this just on the general principle of removing needless cruft; I've never understood why this might have been useful.
- J<
On Thu, 2006-10-26 at 10:26 -0500, Jason L Tibbitts III wrote:
"JK" == Jesse Keating jkeating@redhat.com writes:
JK> The best I've heard so far was carryover from fedora.us...
I guess that if nobody knows of any reason why it should be there, then it doesn't need to be there.
I'll +1 to this just on the general principle of removing needless cruft; I've never understood why this might have been useful.
+1. Let it die.
~spot
On Thu, 26 Oct 2006 10:26:17 -0500, Jason L Tibbitts III wrote:
"JK" == Jesse Keating jkeating@redhat.com writes:
JK> The best I've heard so far was carryover from fedora.us...
I guess that if nobody knows of any reason why it should be there, then it doesn't need to be there.
I'll +1 to this just on the general principle of removing needless cruft; I've never understood why this might have been useful.
IIRC, we've had the choice between:
X-Red-Hat-Base : for top-level menus, which we never set
X-Red-Hat-Extra : for everything else, but fedora.us was not Red Hat
So, fedora.us add-on packages introduced the X-Fedora category to allow for future desktop menu features like adding/hiding/moving base and/or add-on package entries (or entire hierarchies) based on special category values.
On Thursday 26 October 2006 14:24, Michael Schwendt wrote:
So, fedora.us add-on packages introduced the X-Fedora category to allow for future desktop menu features like adding/hiding/moving base and/or add-on package entries (or entire hierarchies) based on special category values.
Given this and Toshio's reply, I still don't see a need/reason to be using this right now.
On Thu, 26 Oct 2006 14:32:42 -0400, Jesse Keating wrote:
So, fedora.us add-on packages introduced the X-Fedora category to allow for future desktop menu features like adding/hiding/moving base and/or add-on package entries (or entire hierarchies) based on special category values.
Given this and Toshio's reply, I still don't see a need/reason to be using this right now.
Doesn't surprise me, since I didn't mean to justify the existance of X-Fedora. Just explained its origin.
On Thu, 2006-10-26 at 10:05 -0500, Jason L Tibbitts III wrote:
"JK" == Jesse Keating jkeating@redhat.com writes:
JK> So for now, can I get votes to remove the --add-category X-Fedora JK> line from the guidelines?
Could we first understand why it was added in the first place? There must have been a reason, and knowing it should make it easy to decide whether or not it's still reasonable.
Fedora.us had this to say (From google cache): http://tinyurl.com/yjxh6l
''' All Categories must be from the standard set (see below), with the exception that the "Application" category should be included where appropriate (ie. for everything that is supposed to be shown in the menus) for backwards compatibility even though it is not listed as a standard category.
Additionally, all Fedora packages must contain the "X-Fedora" category.
For packages that exist in Red Hat Linux, the categories must be the same as Red Hat's (+ X-Fedora).
For packages that are considered essential for end users, the "X-Red-Hat-Base" Category must be added because that's currently the only way to get them listed in the top level menus instead of "Extras" on RH8 or "More foo..." on RH9. '''
-Toshio
packaging@lists.fedoraproject.org