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

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


Reply to: