Russ Allbery writes ("Bug#741573: Two menu systems"):
> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> > IMO if those patches aren't unreasonable then maintainers should accept
> > them, even if they're slightly less automatic than would be ideal.
>
> Sure. I don't think anyone anywhere in this discussion was advocating
> rejecting contributed traditional menu entries in packages.
I did some searches for bugs where trad menu entries or improvements
were rejected by maintainers. I found a great many bugs where trad
menu entries were supplied by a variety of contributors, and accepted
by maintainers.
I did find three which are arguably recalcitrant maintainers:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407750
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609807
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738027
But this is a gratifyingly low level of obstruction.
> I do think that "should" in Policy is stronger than that, and I don't
> think just weakening "should" for all of Policy is the right solution to
> this bug. I also don't know if Bill would be happy with a weaker version
> of "should" that's akin to how we handle man pages in practice.
I think the best approach would be to make it clear somewhere in the
introduction to the policy manual that the maintainer can reasonably
decide that a package is acceptable even though it fails to comply
with a "should".
That's not to say that tools like lintian shouldn't warn about the
lack of menu entries the same way they warn about lack of manpages.
> I think doc-base integration is a fairly similar case, BTW. In that case,
> Policy says that it is "recommended practice," which policy defines as
> equivalent to "should." If anything, doc-base is probably less used by
> end users than the traditional menu. (Personally, I think man pages are
> more important than either, but man pages are also more work, and that's
> to some extent personal preference.)
Right. I think this bolsters my line of argument that policy already
uses "should" in exactly the sense which is appropriate for the Debian
menu.
> I don't think anyone previously has laid out the two systems the way
> that you did as having far different content *by design* instead of
> just by accident. I certainly hadn't been thinking of it that way.
It seemed obvious to me after reading the bug log, which contains
conflict not just about file format and technicalities, but also about
the purpose and desired content of the menu system.
Of course the participants in the discussion were approaching the
discussion on the basis that they are arguing about what the assumed
single menu system should be like. But it seems to me that we can
give everyone what they want by explicitly saying that these two
systems should coexist.
Of course a flipside is that it should be straightforward to cause
the trad menu to be accessible via a desktop system's menu, even if
the desktop system hides it by default. I don't think anyone disputes
this either, though.
> That may be an interesting way forward and remove a lot of tension. The
> traditional menu would be for absolutely everything and the kitchen sink,
> and desktop files would only be for programs that have reasonable
> integration into a more typical GUI environment.
Right.
> I think drawing that distinction clearly in Policy (which it does not
> currently, since it doesn't mention desktop files at all, and which I
> don't think the proposed patch does either) would provide a lot more
> guidance about what people should do in practice and also provide more
> explicit blessing for window manager packagers who aren't interested in
> the all-encompassing menu to drop it (at least by default). That might be
> a useful way to resolve this conflict and put to rest the periodic
> arguments about whether, say, shells should have menu entries. They would
> have traditional menu entries but not desktop files, and we could say that
> explicitly.
Exactly. I think the best way to deal with this is to have two
separate policy sections, one for each menu system. That way there
won't have to be any disputes about what the text ought to say.
Each of those two sections should use the same "should provide"
wording, qualified by the appropriate explanation of the intended
scope of that menu.
Ian.