[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 11:32:17 +0200 (CEST), Andreas Tille <tillea@rki.de> said:

    Andreas> 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
    Andreas> What is the problem with

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

    Andreas>   less /usr/share/doc/cdd-dev/examples/menu/README cp
    Andreas> /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

    Andreas>   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.

    Andreas> Hmmm, I see no real point in creating an interface where
    Andreas> 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.

    Andreas> IMHO the effort to write such an interface is much to
    Andreas> high if you keep in mind that a developer has to have
    Andreas> basic skills like reading REAME files copying and editing
    Andreas> 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.

    Andreas> Well there are templates.  I would say, I would not
    Andreas> really like to use CDD packages created by a person who
    Andreas> is unable to work with these (perhaps they could be
    Andreas> enhanced and better documented, but that's all).

Ok, I understand all your arguments,  which are the  same doubts I had
myself. So, fine for me, let's drop this..

    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?

    Andreas> Perhaps.  The check would have to parse the "Depends:"
    Andreas> line of debian/control and verify that there is a valid
    Andreas> menu file in /etc/cdd/#CDD#/#role#/#CDD#-#task# The
    Andreas> #role# issue might cause roblems before we did a goof
    Andreas> definition what's reasonable here.  Thus we should move
    Andreas> such kind to low priotity on the TODO list ...

Ok,  is there  a  way  to open  Feature  Request and  ToDo trackers on
Alioth,  as   an ordinary GForge site?   I  find GForge  trackers very

    >> I see. Anyhow probably even the cfengine configuration files
    >> should be divided on per-task bases.

    Andreas> 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.

    Andreas> 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.

    Andreas> Debconf and cfengine are optional.


So, to summarise the whole  thing, it turned out that  the bricks of a
CDD   are task packages,  that,    besides mere dependencies,  provide
various types additional information for the packages they depend on.

Currently these types  are menu (recommended), debconf  (optional) and
cfengine (optional), but new needs may arise in the future.

I'd  suggest to  change the  structure of  the CDD source  packages to
reflect more cleanly this concept of task with attached information.

What do you think about something like:

  |_ debian/
  |_ tasks/
       |_ common/
       |    |
       |    |_ README
       |    |_ control
       |    |_ conf
       |_ task1/
            |_ README
            |_ [*.]control
            |_ [*.]menu
            |_ [*.]debconf
            |_ [*.]cfengine
            |_ ...

where [*.] means that files  can optionally be splitted in  sub1.menu,
sub2.menu or sub1.cfengine, sub2.cfengine, if files get to big.

The "common"  task is mandatory, because it  provides it registers the
CDD  in  /etc/cdd,  provides   role   support (it  might   extend  its
functionalities in future).

The "control" files are equivalent to the former tasks/* files.

Then  debhelper like scripts take  care of properly handle the various
information, installing files and possibly   adding chunks of code  to
the postinst and postrm scripts:


Finally I've  read  that cdd-install-helper currently scans  the docs/
directory for .txt files.   If  understand correctly these .txt  files
should be written in case a given package has no menu entry, isn't it? 

In this case  I think that  we should either file   a bug against  the
package which doesn't provide the menu file, or  generate a menu entry
which displays the man page of such  package, rather then an home made
.txt file. If even the manual page is present, then  this is a serious
bug of the  package and we should  try to write  it and send it to the

    >> 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.

    Andreas> Sure.  BUt it could be obtained from the same base of
    Andreas> information.

Yes,  all   the  need information would   be   contained in the  task/

    >> 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>.

    Andreas> Perhaps.  I more or less thought about keeping Debian
    Andreas> websites up to date or whatever.  It should contain more
    Andreas> general information and is not necessarily intended for
    Andreas> local documentation (even if this is no contradiction).

I think that  debian website can  simply  use the files  contained in,
let's say, mycdd-doc, which  contains documentation in various formats
(i.e.  suitable for various  type of  display)  and is generated  by a
debhelper script (cdd-install-doc?).

Simply my 2 cents..

Free Ekanayaka

Reply to: