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

Bug#447389: Is menu orphaned? (Was: Debian Menu transition status)



On Tue, 4 Dec 2007, Bill Allombert wrote:

The menu entry format is not documented in the menu policy, so this
discard #447389.

Well, you are right that policy should not _describe_ the menu format,
but policy should definitely _mention_ that there are at least two formats
and should give an _advise_ which to use.  I tend to reopen the bug
(depending from the outcome of this discussion).

Since menu-1 is not deprecated, #447390 is a wishlist.

If menu-1 is not deprecated then lintian should only issue an info.
Please don't blame me for drawing wrong conclusions from perfectly
lacking information.  There was an announcement of a new format and
I tend to assume that a new thing replaces the old one and we should
start informing people about this fact.

I have no feeling about using menu-2 for menu file, but I recommend
it for menu-methods.

But why?

Because this make functions definitions in menu-methods much more readable.
menu-2 is used in menu-methods for 8 years or so.
menu entry files are much simpler. However some people do not like the
fact that line break are significant.

So don't you think that this fact should be written down anywhere?
I can not cope with statements "have no feeling about using menu-2".
If we want a consistent menu system we should give maintainers clear
guidelines.

You explained that the documentation of menu-2 was sub-par. This is
exactly the reason I took five years before learning about menu-2.
I inherited this feature from the original menu author (Joost).

It was not my intention to blame you for the menu-2 issues.  I'm just
missing a clear strategy and because I think that menu has some very
interesting features we should be precise in describing what maintainers
are expected to do.  There are a lot of maintainers who think menu
is a dead horse they should stop riding and switch to freedesktop.org.
If there is no clear strategy written down I can not blame them wrong.

After 8 years and without drawing the consequences to file the
apropriate bug reports especially #447391?  This sounds not very
convincing.

Why should lintian flag menu-1 as an error ? menu-1 menu file are
absolutly fine as far as I am concerned.

Well, the bug report does not say it should mark menu-1 as error.
It says "check for" and if _I_ would be the menu maintainer I would
try to settle dwon with one format.  But if you "have no feelings"
and the difference is just a ';' or a line break we should simply
stick to the "most widely used" and drop the other one.

If you want menu-2 dead, why asking dh_make to generate menu-2 file ?
Why asking lintian to report menu-1 file as error ? Strange...

It becomes strange if you are ignoring that my suggestions are from
different times and there was some gain of information in between.
I admitted to be confused by missing information but I'm not confused
enough to suggest two contradicting things at the same time (hopefully).

 1. I want to be menu-2 dead if menu-1 obviousely is not.
 2. I want to have one single menu format if there is no strong
    reason to support more than one (feelings are no reasons).
 3. I want dh_make to generate files of the _suggested_ format.
    (Your announcement sounded kind of a suggestion for menu-2
    and thus I felt my bug report would be reasonable.)
 4. I want lintian report (just report, not as an error) that
    something else than the suggested format is used.

Anyway, if you have some cdd scripts that are broken by menu-2, please
send them to me and I am sure we will fix them in a short time.

Well, I'm sure that /usr/share/menu/cdd-menu (from cdd-common) can be
fixed to cope with /usr/share/menu/amide (from amide) to create a valid
menu.  The problem is that I'm missing a clear strategy in which way it
should be fixed.  There are several possibilities.  The cdd-menu scripts
concatenates single menu entries to build a user menu.  The concatenation
only works if the input files have the same format.

  Strategy   I: Use menu-1 for single menu entries.
       --> Fix: Ask Amide maintainer to switch to menu-1.  (very simple)

  Strategy  II: Usage of menu-2 is recommended.
       --> Fix: cdd-menu converts every menu-1 entry to menu 2 and
                output a menu-2 formated list of menu entries.

  Strategy III: Menu-2 entries are an exception.
       --> Fix: cdd-menu converts every menu-2 entry to menu-1 and
                output a menu-1 formated list of menu entries.

It is basically not about writing some code (even if I'd be happy to
accept patches of course ;-)) but knowing which code makes most sense.

Actually you can even use update-menus to convert from menu-2 to menu-1.

I doubt that this will work in the cdd-menu case because it just
generates the input for update-menus - but perhaps I missed something.

Another issue is that people think about generating Debian menu entries
from desktop files.  This also would require a clear strategy because
I think it is reasonable to do this conversion into a _suggested_
menu format instead of a random one.

Kind regards

         Andreas.

--
http://fam-tille.de




Reply to: