Bug#707851: Debian Menu Systems : Implementation of the TC decision
On Tue, 2015-09-29 at 11:39:47 +0200, Didier 'OdyX' Raboud wrote:
> Le mardi, 29 septembre 2015, 02.10:01 Guillem Jover a écrit :
> > Wow, this is such terrible policy… So we have supporters of the XDG
> > format, and supporters of the menu format. Some of those would and
> > have accepted files of their non-preferred format in their packages,
> > some have outright refused them. But now they have to choose between
> > one of them, because they can no longer ship both.
>
> One of the points of the TC decision is precisely to avoid a "free
> choice" between the two formats. The first point of that decision is to
> adopt ba679bff76f5b9152f43d5bc901b9b3aad257479 in the Debian Policy,
> which contains:
> > Packages shipping applications that comply with minimal requirements
> > described below for integration with desktop environments should
> > register these applications in the desktop menu, (…)
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.
> The second point of the TC decision (which phrasing to be
> committed in the Debian Policy we're currently discussing) is to forbid
> applications that do provide XDG menu entries to _also_ provide "trad
> menu" entries.
Sure, and that's still terrible policy, and self-conflicting at best with
the rest of the decision.
(Whatever happened to letting technical solutions win or loose for their
own merits, and from work or lack thereof from supporters, instead of by
letting a big broken hammer fall in slow-motion on them…)
> > 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.
So it feels like "let's make a mess, and hope someone else cleans it up
for us when they get sufficiently annoyed".
> and _can_ be completed for the range of
> applications that don't make sense in the XDG menu, but do make sense in
> the 'trad menu'".
> Like it or not, this is decided, and we're "only"
> discussing how this should take form in the Debian Policy.
I don't have a horse in this race except for wanting Debian to be sound,
I just think the decision is very poor. I'm also not trying to discuss
how this should end up in policy. As I've mentioned several times now,
as long as the policy process is overrun by the TC, I've got no
motivation to get properly involved in it. Clearly someone else has
decided to do the job.
> 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.
> > Also is the TC going to implement the changes in the "menu programs"
> > to support the XDG format? Because I don't see the ruling to be very
> > motivating for the menu supporters.
>
> "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.
Regards,
Guillem
Reply to: