Charles Plessy <ple...@debian.org> writes: > I would like to integrate it while keeping the instructions about the > Debian menu and the mailcap entries. Here is my proposition.
> 9.6 : Packages should support at least one of the FreeDesktop and the Debian > menu system. I'm not sure "at least one" does anything useful for us. The situation we're currently in is that if a package does not ship a desktop file, it won't appear in the menus of most of the desktop environments, since they generally hide the Debian menu. If a package does not ship a menu file, it won't appear in the menus for window managers like fvwm. Right now, I think the best advice we can give to a packager is to support both. However, increasingly, our users are using systems where only the desktop file menu items will appear, so I think the desktop file will become more and more important over time. > 9.6.1: The FreeDesktop menu system. Mostly the suggestion from Sune and > Josselin. I would like to add a brief word or a footnote on forwarding > the entries upstream whenever possible. For the layout, I think that > the Desktop Menu Specification is clear enough, and the current practice > is to let each Desktop system implement it freely, rather than aiming at > a unified structure like with the Debian menu system. I do think we should add a link to menu-spec as well as the desktop file spec, though, so that people know what categories to use. > 9.6.2: The Debian menu system. I do not agree with the use of "legacy", > because it does not give guidance on what to do (support or not), and > because in the current context, it has a negative connotation. I would > like to keep most of the current text, and clarify with Bill about > triggers (#707888), as for the moment I do not understand what the > problem is. This also works for me. I think the use of "legacy" is defensible, but I agree that it doesn't provide much useful guidance, and I don't really care. Since others do object to it, it's probably better to avoid the term. > 9.7 : Packages should use destop files unless their entry can only be > expressed in the mailcap format. This proposition is not the current > practice. I intend to give the example (and possibly find corner cases) > with the mime-support package. I propose to patch the policy in Git > with a "should", and review before publishing how packages are evolving > in that direction (a Lintian warning would probably help, if we can > detect which mailcap entries can certainly be translated to FreeDesktop > entries). > 9.7.1: The FreeDesktop menu system: Josselin's text. I would like to > add a recommendation to declare media types to the IANA, which is > upstream of shared-mime-info. I would also prefer to give an example > where the media type does not start witn "x-". > 9.7.2: The mailcap entries, for when something can not be expressed in a > Desktop entry. This all sounds good to me. > For media types, there is at least one more provider: the 'file' > package. I wonder if there is something to mention there, or if it is > more relevant for other guides. Is there anything the maintainer of a package should be doing with respect to the file package? I was assuming that file upstream would take care of adding new entries. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874ne5uo29....@windlord.stanford.edu
