Distributions

Debian and application-menu policies

By Nathan Willis
May 7, 2014

The Debian project is engaged in a debate over how the Debian menu is presented in various desktop environments and what policy for application packaging should be derived from that decision. The recent trend in desktop environments has been away from a master "applications menu," but Debian's response to that shift has as much to do with internal project-management processes as it does with updating packaging recommendations.

Back in May 2013, the issue of moving away from the Debian menu (which contains a categorical hierarchy of application launchers, as was a common feature of most desktop environments in years past) was first raised in a bug filed by Sune Vuorela. The original goal of the Debian menu was to provide a consistent way to access installed applications, regardless of which of Debian's many available desktop environments was in use. Over the years, however, the style and interface conventions of those various environments have shifted away from the one-master-menu approach.

Vuorela's bug report noted that the Debian menu was now hidden by default in GNOME, that a similar change was under consideration for KDE, and that many application packages had stopped including the menu-entry description files needed by the Debian menu in the first place. The recommended change was to soften the language found in Debian's official policy manual that told application packagers they should create a menu entry; instead, creating a menu entry would be an option, but the more important factor would be creating a .desktop file that could be used by the search-driven interfaces of GNOME Shell and other recent desktop environments (though it could also be used by menu-driven environments).

Of course, the Debian menu itself has had both fans and critics over the years. When shown, it frequently presents duplicates to a number of entries also found in the GNOME or KDE menu structures, which seems superfluous. On the other hand, Debian can control the content of the menu to a much greater extent, which makes it more predictable—it is always possible to find a utility in the Debian menu, the argument goes, even if the same utility gets removed or reclassified into a hard-to-find spot in the desktop environment's menu structure.

But much of the work of making the Debian menu usable fell on application packagers, who were tasked with creating the menu file for each package, and the Debian menu-entry format uses a distribution-specific syntax. Meanwhile, GNOME, KDE, and the vast majority of other desktop environments have agreed on the Freedesktop.org desktop entry specification for .desktop files, which covers most of the same metadata for each application.

Eventually, a proposal formed to recommend that packagers migrate away from the Debian menu-entry format to the Freedesktop.org .desktop format—in essence, deprecating the Debian menu in favor of the Freedesktop.org system (however it might be implemented in any particular desktop environment). In early 2014, the proposal picked up steam again (after several months of inactivity) as a possible change to be included in the upcoming Debian "jessie" release, and on February 15, Charles Plessy checked in the change to the policy manual.

Not everyone was satisfied, however. Bill Allombert (who along with Andreas Barth, Jonathan Nieder, and Russ Allbery, is a Policy Editor) reverted the change on February 25, arguing that a number of objections to the proposal had not been addressed, and, thus, "there is no consensus in favor of this change, so committing to policy was premature." Vuorela and others disagreed, insisting that all of the objections listed by Allombert had been answered, and concluding that "there is a consensus. Note that consensus doesn't mean unanimous."

Plessy contended that Allombert had sat out of the discussion over the preceding year, and that a majority of Debian Developers and Policy Editors had approved it. Stepping in after the decision and reverting it, he said, amounted to single-handedly vetoing the change. Plessy suggested taking the issue to the Debian Technical Committee (TC) for a resolution, and after another reply from Allombert did not seem to change matters, filed a bug on the subject with the TC on March 14.

While escalating the issue to the TC might seem to focus on the issue of whether one member of a team (in this case, the Policy Editors) can overrule a consensus reached by the others, that is not in fact the direction that the TC discussion took. As Ian Jackson said:

This is hardly the first time that a matter has come to the TC after a dispute has escalated to acts (on one or both sides) whose legitimacy is disputed. I doubt it will be the last. Our approach has always been to look at the underlying dispute and try to resolve it.

So, no. The TC will not make decisions about the content of policy on the basis of an adjudications about the policy process. We will rule on the underlying question(s), on the merits.

Instead, the TC discussion returned to the original question of whether or not the Debian menu remained a useful feature even in light of the increasing usage of Freedesktop.org standards by desktop environments. As was the case in the original bug's discussion thread, there are arguments from many different perspectives regarding situations where the "traditional" Debian menu might be better than a modern Freedesktop.org menu. They included technical concerns, like the fact that the Debian menu expects application icons in XPM format and at no greater size than 32-by32 pixels (both of which make for a less-than-pleasing image on modern displays), and implementation concerns, such as who would be tasked with creating the .desktop files for the various application packages.

Also raised as a concern is the degree to which the policy manual specifies what developers and packagers must do versus what they optionally can do. Both the old policy wording and the patched version say that shipping applications "should" include a menu entry in the specified format. But "should" can be interpreted either as a requirement—meaning that an application without the menu entry it "should" have will not be included—or as a recommendation that does not necessarily demand every application conform.

And, on that point, the TC does not yet appear to have arrived at a consensus. Debian has thousands of packages; if the policy is changed in such a way that developers and packagers are required to create .desktop files, the result could potentially be thousands of hours of work. Imposing such a requirement with a simple wording change does not seem to be an ideal move.

On April 13, Allbery noted that the "should" wording had resulted in a logjam in the discussion. The next response came on May 5, when Plessy appealed to the TC to reach a decision:

More than one month and a half later, Bill still has not explained his position to the technical committee.

In that context, I am asking the TC to a) acknowledge that the changes to section 9.6 after the Policy changes process was followed accordingly, and b) ask for Bill's commit 378587 be reverted. In particular, in the absence of Bill's contribution to the resolution of our conflict, I am asking the TC to not discuss the menu systems and focus instead on correcting Bill's misbehaviour.

What is at a stake here is not the Debian Menu system, it is the fact that in Debian, it takes 5 minutes for one person to block one year of effort and patience from multiple other persons.

At this point, it is not clear what the TC will do next. Over the course of the "should" discussion, it became clear that Debian's policy manual is not entirely consistent in the wording with which it describes requirements and recommendations. Worse yet, it became clear that not all members of the project agree, even when confronted with a single word. Whether or not further discussion can resolve those issues is hard to say, but Debian, at least, is no stranger to lengthy debates.

Comments (29 posted)

Brief items

Distribution quote of the week

Ultimately, if users want to see their distro thrive and survive they have got to roll their sleeves up and muck in a bit. Leaving it all to 'someone else' will not get the job done.

-- John Crisp

Comments (2 posted)

CyanogenMod 11.0 M6 is available

The developers of the CyanogenMod Android derivative have announced the availability of the 11.0 M6 release. The announcement also includes details about changes in the release scheme; there will be no more "stable" releases; instead, the project will attempt to produce reliable "M" releases with increasing frequency. "Our goal is to get a release out every 2 weeks with the same quality and expectations you would have of a ‘stable’ release (label for that yet undecided). But with that goal, it further underscores how the label ‘stable’ no longer works for us. With the current M cycle, we have gotten our routine down to every 4 weeks; to get it to 2 weeks is ambitious, but we can do it, and it would benefit everyone." See the announcement for a list of changes in this release.

Comments (129 posted)

OpenBSD 5.5

OpenBSD 5.5 has been released. OpenBSD is now ready for 2038. The entire source tree has been audited to support 64-bit time_t. This release also features numerous improvements across the distribution. See the changelog for a comprehensive list.

Comments (34 posted)

OpenMandriva Lx 2014.0

The OpenMandriva Community has announced the release of OpenMandriva Lx 2014.0 Phosphorus. "The kernel has been upgraded to 3.13.11 nrjQL – a powerful variant of the 3.13.11 kernel that has been configured with desktop system performance and responsiveness in mind. To achieve this the CPU and RCU have been configured with full preemption and boost mode, and the CK1 and BFQ patchsets have been added to provide further optimisations (including better CPU load and disk I/O schedulers, an improved memory manager using UKSM, and TuxOnIce providing suspension and hibernation services." See the release notes for details.

Comments (none posted)

Distribution News

Debian GNU/Linux

Bits from the Release Team - Freeze, removals and archs

The Debian release team talks about freezing "jessie" in 6 months, long term support for "squeeze", architectures, and more.

Full Story (comments: none)

Ubuntu family

Ubuntu 12.10 (Quantal Quetzal) reaches End of Life

As of May 16 Ubuntu 12.10 will reach its end of life. There will be no more updates after that time. Users of 12.10 are encouraged to upgrade to 14.04 via 13.10.

Full Story (comments: none)

Newsletters and articles of interest

Distribution newsletters

Comments (none posted)

Why ARM Servers, And Why Now? (EnterpriseTech)

Timothy Prickett Morgan takes a look at how the ARM server ecosystem is coming along. "As Canonical announced two weeks ago, Ubuntu Server 14.04 LTS is the X-Gene 1 from Applied Micro and the Thunder from Cavium Networks. Red Hat has demonstrated its Fedora development Linux on the X-Gene 1 and AMD’s “Seattle” Opteron A1150 processors, and Jon Masters, chief ARM architect at Red Hat, said at the ARM Tech Day that 98.6 percent of the packages in RHEL are “ARM clean,” and added that this is a full-on 64-bit implementation of the stack and that Red Hat would not support 32-bit code and that the support for 64KB memory pages made it impossible to do a 32-bit port. That said, you can always load a virtual machine with a version of Linux that does support 32-bit code if you need to, said Masters. Red Hat will not comment on when or how ARM support will be available with the commercial-grade Enterprise Linux, and a lot depends on the availability of hardware that supports various standards (UEFI and ACPI for instance), demand from customers, and the readiness of key programs such as Java. SUSE Linux has added support for ARM chips in the openSUSE development version and is very likely shooting to have ARM support in Enterprise Server 12, due to go into beta maybe later this year for production next year."

Comments (26 posted)

OpenELEC 4 offers simple XBMC install for standalone devices (BetaNews)

OpenELEC is a complete Linux distribution based around the XBMC media player. BetaNews reviews the recently released OpenELEC 4.0 which includes XBMC 13.0. "The biggest change to OpenELEC 4.0.0 is the completely reworked build system. This doesn’t just fix outstanding issues, but makes it easier for the development team to add new features going forward. It also leads to a simplified number of builds, with specific builds for certain chipsets (including NVIDIA ION, Intel and Fusion) now removed, with support rolled into the generic 32-bit and 64-bit builds instead."

Comments (none posted)

Page editor: Rebecca Sobol
Next page: Development>>