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

Re: CDD Tool Proposal

On Thu, 9 Dec 2004, Sergio Talens-Oliag wrote:

Pkg-Menu: My/Custom/Path

if it's declared then the package(s) included in subsequent Depends/Recommends/Suggests
will have the standard menu path overridden by that custom path.

 Hmm, I don't really see how this would work right now, but I'll add it to
Well, it just works like any other menu entry.  Just read


about the "Section" entry.  If you implement the feature to add override menu
entries you get this feature for free.  Just insert "My/Custom/Path" in the
Section field of your menu entry and you are ready.  Perhaps somebody would
like to make this more user friendly, but the functionality is there as
well as the code to prepend the section field by a certain field (in the
user menu entries the Section field is prepended by the CDD name).

So I fail to see the feature Free is missing.

 My idea is that all the menus related to a task can be put into a directory
 and included only once:

   Task: Foo1
   Task-Menu: menus/
Shouldn't it be
     Task-Menu: menus/Foo1                    ?
How would you specify to which task the menu items belong.  This brings the
idea to my mind you might obtain the task by the Dependencies of the package
and the menu items have to be named like the dependant (recommendet + suggested)
packages.  But I wonder if we would miss some flexibility here.

 or each set of packages can declare the menus realated to it independently:

   Task: Foo2

   Depends: package1
   Task-Menu: menus/program1.1.menu, menus/program1.2.menu
   # Includes two menu files on the task

   Depends: package2
   Task-Menu: menus/package2/
   # Includes all menu files present on the directory to the task
I'm afraid I do not clearly understand.  We need at most one menu entry per
dependant package (as each Debian package holds only a single menu package)
but we might need one (and only one) menu entry per every single Depends /
Recommends / Suggests (and perhaps even Conflicts to inform the user *why*
we used this conflict - but this might be nonsense).

Kind regards



Reply to: