El Thu, Dec 09, 2004 at 03:56:25PM +0100, Andreas Tille va escriure:
> On Thu, 9 Dec 2004, Sergio Talens-Oliag wrote:
> > 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 ?
Well, it was just an example and the meaning depends on how you plan to
organize your files, the idea is that all menu files on the directory will
be added to the task, if you organize your CDD like:
cdd/
cdd-control
base-config/
task1/ ... taskN/
cfg-scripts/
task1/ ... taskN/
debconf-pressed/
task1/ ... taskN/
installer-pressed/
task1/ ... taskN/
menus/
task1/ ... taskN/
Then the Task-Menu would be what you said, but my example is written
thinking about a model like:
cdd
cdd-control
task1/
task1-control
base-config/ cfg-scripts/ debconf-pressed/ installer-pressed/ menus/
...
taskN/
taskN-control
base-config/ cfg-scripts/ debconf-pressed/ installer-pressed/ menus/
> 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.
Yes, this would reduce flexibility and anyway the model already allows that
using the Task-Menu as I said on your next quote:
> > 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).
Probably you are right and we don't need more than one menu for each package
(my fault, as I said I don't use menus and have to review the debian menu
policy), but anyway the feature still applies, because each paragraph can
include more than one package:
Task: Foo
Depends: pkg1, pkg2, pkg3
Recommends: pkg4, pkg5
Task-Menu: menus/pkg1.menu, menus/pkg4.menu
Depends: pkg6, pkg7, pkg8
Suggests: pkg9
Task-Menu: menus/pkgs6-9/
Does this make sense?
Anyway I'll review the menu system and how you are handling it, to discuss
things with a better knowledge of what we want.
Greetings,
Sergio.
--
Sergio Talens-Oliag <sto@debian.org> <http://people.debian.org/~sto/>
Key fingerprint = 29DF 544F 1BD9 548C 8F15 86EF 6770 052B B8C1 FA69
Attachment:
signature.asc
Description: Digital signature