Re: Which packages a CDD is composed of? [Was: Integrating cdd-dev with dh-make]
[I think there is nothing private in this mail. sorry if I quote you
in public but since April 2, the time where we keep CDD-mails in private
is fortunately over. ;-)]
On Mon, 26 Apr 2004, Free Ekanayaka wrote:
> I meant that the cdd-addpackage script (or whatever we want to name
> it), would just be a command line script to add a package to a
> tasks/<TASK> file, which possibly checks whether a menu file for such
> package is present in /usr/lib/menu and, if so, copies it to the menu/
> directory, maybe automatically replacing the section= field according
> to the title of the task.
Ahh, yes OK. But something remains unclear: Do you intend this to be done
on the package developers machine who builds the task package or on the
users machine who installs the task package?
> Yes, you're right. Task packages and relative custom menu files have
> to go together. So let's drop the <CDD>-menu package, and let's extend
> the task package definition with something like:
>
> 1) Task packages, named <CDD>-<TASK>. A task package depends on all
> the packages that a CDD considers relevant for a specific domain,
> and {must|is supposed to|should} provide custom menu files for
> them, typically changing the hierarchy structure or introducing ad
> hoc command line options . A system administrator or a user can
> update the the menu hierarchy by calling cdd-update-menus.
>
> We have to decide whether to allow packages without menu files or not.
We should allow this. Current implementation of cdd-install-helper throws
a warning. Just try to build debian-med packages to verify this and see
how it works.
> Personally I would like to always see a menu entry, possibly pointing
> to a man page in case of command line tools without a GUI. This way we
> make sure that all the components of the CDD are visible.
Same for me but I think we should allow it while throwing warnings
or errors. Here we come to some other tools which should possibly
support CDD: lintian / linda could handle those issues.
> Andreas> I can't comment on this because I do not know cfengine.
>
> I didn't know it either before looking at the debian-edu-config
> package. Now I found it wonderful. Please consider to have a look at
> it.
Sure. But currently I did not have a usage in the med-* packages.
> Uhm, basically cdd-list would be wrapper around apt-cache, I'm not
> sure if it worths..
Well, id would be a wrapper around either apt-cache or grep-dctrl or
any other tool but it is definitely worth the effort because you
can do more than this command line stuff. What about a switch like
-htmloutput (or -wmloutput)
to build web pages from installed / available <CDD> packages for
instance? What about a -lang switch which might work together with
ddtp translated descriptions (hopefully this will start working again)?
There are several useful applications which gon into the field of
reasonable but easy to obtain documentation.
> Yes that would definitively be the best option. But I'm assuming that
> it's difficult to go that way right now.
SUre. If it would not be difficult it would be solved right now.
> Anyhow we can choose that
> tasksel is really what we want, push for it and wait till we get the
> bug accepted and fixed.
I guess waiting is not enough. We have to ask for it frequently providing
patches and reasonable suggestions.
> As a temporary work around we can write a debhelper script which
> automatically generates the debian/control entry for the installation
> package. In the meantime we keep pushing for more elegant solution.
Feel free to fix cdd-gen-control in CVS ... ;-)
Kind regards
Andreas.
Reply to: