[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]

On Tue, 27 Apr 2004, Free Ekanayaka wrote:

> mkdir mycdd-0.1
> cd    mycdd-0.1
> dh_make --cdd (or some equivalent)
> then you may want to add task and packages:
> # creates a new tasks/mytask file
> cdd-addtask --menu-title "My Task" mytask
What is the problem with

  less /usr/share/doc/cdd-dev/examples/tasks/README
  cp /usr/share/doc/cdd-dev/examples/tasks/task1 tasks/mytask

  less /usr/share/doc/cdd-dev/examples/menu/README
  cp /usr/share/doc/cdd-dev/examples/menu/task1 menu/mytask

> # add an entry to tasks/mytask,
> # checks if mypackage is installed,
> # and, if available, copies the menu file in menus/, replacing the section= entry
> cdd-addpackage --task mytask mypackage

  vi tasks/mytask
  vi menu/mytask

> Please note, that this just a rough idea.  The goal would be to create
> a simple interface to work with a source CDD package.
Hmmm, I see no real point in creating an interface where a simple editor
could do the job.

> We  may even decide  that we do not  need  such additional scripts and
> that we prefer manually editing the files.
IMHO the effort to write such an interface is much to high if you keep in
mind that a developer has to have basic skills like reading REAME files
copying and editing templates.

> What I have  in mind is that  having  such scripts would  simplify the
> creation of draft cdd source  packages (e.g. you have  a list of 30 or
> 40 packages), then you can do little tunings by hand.
Well there are templates.  I would say, I would not really like to use
CDD packages created by a person who is unable to work with these (perhaps
they could be enhanced and better documented, but that's all).

>     Andreas> Same for me but I think we should allow it while throwing
>     Andreas> warnings or errors.  Here we come to some other tools
>     Andreas> which should possibly support CDD: lintian / linda could
>     Andreas> handle those issues.
> This is a  really good idea.  It would be just a  matter of writing  a
> lintian/linda plugin test. Shall we add this to the TODO?
Perhaps.  The check would have to parse the "Depends:" line of
  debian/control and verify that there is a valid menu file in
The #role# issue might cause roblems before we did a goof definition
what's reasonable here.  Thus we should move such kind to low priotity
on the TODO list ...

> I see. Anyhow probably even the cfengine configuration files should be
> divided on  per-task bases.
Probably.  I see no reason for splitting.

> Thus a better definition of a task package would be:
> Task packages are named <CDD>-<TASK>.
> A  task package  depends on all  those  packages that  a CDD considers
> relevant for a specific domain.
> Furthermore a  task package takes care  of  adapting the package which
> depends on in various ways. Typically:
> * Custom menu files, that change  the menu hierarchy structure  and/or
>   introduce  ad hoc command line  options. A system administrator or a
>   user can update the the menu hierarchy by calling cdd-update-menus.
Menu is suggested or recommended.

> * Custom  debconf values, that are  injected the debconf database when
>   the  task is installed, transparently  configuring  the packages the
>   task depends on.
> * A  set of cfengine  configuration  files,  which  define  actions to
>   modify  and tune the packages  the task depends on, whenever debconf
>   is not suited for that.
Debconf and cfengine are optional.

> I like the idea,  but  I would  keep separate the  installation  issue
> (i.e. having  a simple way to  install all the  packages of a CDD) and
> the automatic documentation one.
Sure.  BUt it could be obtained from the same base of information.

> For the former  the  best  option would   probably be  tasksel,  as we
> stated, and I as  a temporary  solution I think  that a  package named
> exactly as   the CDD  which    depends on  all  its   packages and  is
> automatically generated by a debhelper script is ok.
> For the  latter we may want to  provide another dedicated  tool, maybe
> another debhelper script which generates  and install documentation in
> /usr/share/doc/<CDD>.
Perhaps.  I more or less thought about keeping Debian websites up to date
or whatever.  It should contain more general information and is not
necessarily intended for local documentation (even if this is no

Kind regards


Reply to: