Re: about commit debian-edu r40399
On Thu, 28 Feb 2008, José L. Redrejo Rodríguez wrote:
I have not a strong opinion on it, but from a purist point of view, any
of the metapackages work perfectly without the menu packages, so it's
not a dependency. On the other hand the menu package produces no effects
unless the user is added to the right groups (students or teachers in
this case), so any other user won't see any effect with him. We can say
that the package won't hurt if installed, but I don't see it as a real
dependency.
From a purist point of view you are right and I agree that we should
work it out as "Recommends".
Perfect, then I think we should begin to work on it. I don't know how
you would like to do it. You know much better the insides of cdd and
where to "touch" to do things.
Well, things probably have to be touched in cdd-gen-control. It is
basically a factorized gen-control from debian-edu before we switched
to cdd-dev. The dependency from CDD-tasks is added near the string
"if ( $tasksname =~ /-tasks$/ ) {" in the code. At this place it is
ensured that CDD-tasks gets a real Dependency (instead of a Recommends)
which is probably void if we settle down to go with Recommends for
the CDD-menu package. But I would vote for a versioned Recommends
CDD-menu (= ${binary:Version})
IMHO this increases consistence even if chances are good that in most
cases the correct version will be installed anyway and I see no real
chance to break anything if versions do not match.
I think we have to decide:
- How to detect the requirement to add CDD-menu to the Dependencies.
-> IMHO it would be the most comfortable solution for the user
to add such a package when a non-empty menu directory exists.
Regarding the name I see a heavy potential for mixing this up with the
directory named "menu" with the old menu stuff (based on the
Debian-Menu system). So my suggestion would be to use a FreeDesktop.Org
directory for instance named "fdo" (feel free to find a better name)
and put below this directory everything that is needed:
fdo
+---> desktop-directories
+---> menus
+---> pixmaps
So cdd-gen-control checks for the existence of a non-empty
directory fdo/menus, adds the needed snipped of code to
debian/control (in the same way as it is done with CDD-config)
and adds a Recommends to any of the meta packages.
- Do wee need a switch do force a "Depends" or is "Recommends" the
way we do it (for the moment)?
-> I think this would be reasonable.
- Finally we should either add some code to cdd-install-helper to copy
the files in fdo into the right location. Alternatively we might
work with debian/CDD-menu.install files. This can be done by adding
the according dh_install lines to a to be created templates/menu.install
file. This template can be handled the same way as it is done with
the templates for templates/config.*
Every option is not really hard to implement if you are fairly
comfortable with Perl and shell. I could do this as well once
we decided for the best approach. I would wait with coding anyway until
the #468345 and "friends" issue is fixed. (I have a fix on my local
disk but can not commit before tonight.)
Also, once it's done, the menu package is
pretty simple and easy to understand. Anyway, there is a part that I can
not see how to automate, and should be done by hand: selecting where you
want to put the applications and removing them from the menu branches
where the original package put them. So, in brief, I don't have any idea
about how to begin to do it, so I'm open to any opinion and ready to
help and work on it.
Well, I think the best thing for me to understand would be if I try to
implement something similar for Debian-Med. From a first view I see some
good chance for factorisation if I look at desktop-directories. It looks
like most entries could be auto generated from the tasks names including
their tranlsations. So _if_ we would provide a translation for the
tasks name inside the tasks file - which would make perfectly sense
also regarding building the auto generated web pages - we could in principle
generate most of the desktop-diretories entries automatically. On
the other hand there is no real 1:1 mapping between tasks files and
dektop-directories and I wonder whether you can comment on the
rationale behind this and whether you think it makes sense to try
to make the tasks files as the main source of information here as well.
(Something like "Create-Desktop-Directory: yes" inside the tasks file
comes into mind ...)
The same seems to be valid for menus/applications-merged.
What do you think about thiss?. I'm not really sure whether we end up
in making a science from the task to build some simple meta packages
and try to stretch the wish to get things automatically done to far
or whether we should consequently stick to the idea of having one single
source of information about the tasks (=the tasks files) and obtain
any information from there while making sure that there is no duplication
of the information hanging around anywhere - which makes the stuff
error prone and hard to maintain for more than one maintainer.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: