[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#741573: Two menu systems

Keith Packard writes ("Bug#741573: Two menu systems"):
> Yeah, there are a lot of inappropriate entries in my /usr/share/menu
> directory. Can we fix policy to weed these out? The current
> wording in §9.6:
>       All packages that provide applications that need not be passed any
>       special command line arguments for normal operations should
>       register a menu entry for those applications.
> seems problematic to me -- it seems to require menu entries for things
> as diverse as a web browser and a python interpreter. Coming up with
> wording that encourages only programs which are conventionally used in
> interactive mode to be included seems like a good fix here.

I think this is the heart of the disagreement.

The traditional Debian menu system (mostly done by Bill Alombert) has
been providing menu entries for bc and dc and everything for years.
That is what its users expect.  It is what users like Matthew Vernon

What you are suggesting above is that the Debian menu will simply be
abolished.  No-one will be allowed[1] to provide a comprehensive menu
in Debian.

The present dispute has arisen because, although the traditional
Debian menu maintainers do almost all of the work of providing all the
needed patches to enable packages to provide menu entries, some
package maintainers have decided to block that work by refusing the

It does appear that the users and developers of the .desktop-style
menus are in a majority.  But there are users who want to use the
comprehensive traditional Debian menu, and there are developers who
want to continue to do the work to keep it up to date.

We don't allow maintainers to block translation updates; we don't
expect them to block the provision of manpages (even though some
people think manpages are obsoluete); we shouldn't allow them to block
the trad menu system updates.

And we should certainly not tolerate this deliberate dismantling of a
working and maintained system, simply because some of its opponents
consider it obsolete.  A facility should be declared obsolete when it
no longer has maintainers who can (or want to) keep it working.

At the very least if we declare the trad menu system protocol
obsolete, there should be a clear plan for how to provide _the same
menus_ via .desktop files.  That *doesn't* mean `the menus that the
.desktop file proponents think everyone should want'.  It means `the
menus that the trad menu system users and developers currently have,
and actually want to keep'.



I say `no-one will be allowed' because in the absence of support
from policy, attempts by menu developers to provide entries for
non-desktop programs, will be thwarted by the individual package

If I may extend the transation analogy: if we were to remove the
material about translations from Debian's normative documents, and
declare translations obsolete (in favour of English, I suppose),
no-one would be allowed to make a comperehensive translation of
Debian.  That is because there would be some maintainers who would
simply refuse to take translations on the grounds that translations
are obsolete and it's not worth the small effort to integrate
translation patches.

Reply to: