Le mardi, 29 septembre 2015, 14.34:35 Guillem Jover a écrit : > Which contains the requirements for the XDG entry, one of those being > the icon. If the upstream part does not contain a suitable icon, then > removing the XDG entry and any relevant icon shipped in the debian/ > directory makes the application obviously non-compliant. > > > Applications "should" be registered in the FreeDesktop menu if that > > makes sense. > > For a menu supporter who packages applications for their own use, > I'd presume it would be obvious that making them inaccessible from > their non-XDG compliant environment makes no sense. Two points here: * so far, both in the Policy and during the TC discussion, these "menu supporters" have been _mostly_ hypothetical; * these entries would be absent as long as the "menu program" fail to properly use the 'XDG menu' entries, that's the point of the TC decision. > > > So we might end up with packages by menu supporters removing > > > .desktop files, and packages from XDG supporters removing .menu > > > files. And users of either format caught inbetween. > > > > The TC decision is saying "XDG menu is now the source, it should be > > read by 'trad menu' programs, > > W/o anyone to implement this in the menu programs, this is just > wishful thinking, and might leave big chunks of our users with > inaccessible applications. On either side of the fence. Yes. That's exactly the point: the work to keep the 'trad menu' relevant is to be made by those who care about it. > > In the light of the TC decision, I would personally consider a > > package dropping an XDG desktop entry in favor of a menu entry > > buggy (although there will certainly be cases debatable cases). > > To me this is the equivalent of a package with suitable applications > for the XDG menu, not currently shipping an XDG entry. So now you > declare all those insta buggy as well. Not anymore buggy than with the previous "trad menu" policy (§9.6 in 3.9.6), for what is worth: it said: > All packages that provide applications that need not be passed any > special command line arguments for normal operation should register a > menu entry for those applications. Large parts of Debian have been buggy under this text, for a long time. > > "The TC" is not going to engage in detailed design work (or > > implementation work, for what is worth), although any of its members > > could (but I don't see this happening). > > Exactly my point. This is the equivalent of mandating that the Debian > Future Team should design and implement an FTL engine, where of course > the TC has not engaged in any design work. This to me fails §6.3.5. I obviously disagree, but invite you to challenge this decision in forums other than the debian-policy list. Second, the TC has not mandated any work to any particular team: it changed the ecosystem in which the 'trad menu' programs evolve. Mind you, program ecosystems evolve all the time; 'trad menu's was relying on the Debian Policy mandating entries for all applications "that need not be passed any special command line arguments", the TC decision drops that requirement. -- OdyX
Attachment:
signature.asc
Description: This is a digitally signed message part.