Bug#707851: debian-policy: soften the wording recommending menu files
Charles Plessy <plessy@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: