[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 Mon, 26 Apr 2004 16:04:26 +0200 (CEST), Andreas Tille <tillea@rki.de> said:

    Andreas> [I think there is nothing private in this mail. sorry if
    Andreas> I quote you in public but since April 2, the time where
    Andreas> we keep CDD-mails in private is fortunately over. ;-)]

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

    Andreas> Ahh, yes OK.  But something remains unclear: Do you
    Andreas> intend this to be done on the package developers machine
    Andreas> who builds the task package or on the users machine who
    Andreas> installs the task package?

The first you said, that means a possible work-flow of a CDD developer
would be:

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

# 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     

Please note, that this just a rough idea.  The goal would be to create
a simple interface to work with a source CDD package.

We  may even decide  that we do not  need  such additional scripts and
that we prefer manually editing the files.

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.

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

    Andreas> We should allow this.  Current implementation of
    Andreas> cdd-install-helper throws a warning.  Just try to build
    Andreas> debian-med packages to verify this and see how it works.

Ok, fine for me. I'll try that.

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

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

    Andreas> Sure.  But currently I did not have a usage in the med-*
    Andreas> packages.

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

Since every cfengine  action that a  CDD defines is supposed to modify
some aspect of  an installed package,  perhaps it would make  sense to
include  the  cfengine configuration  file  in which  such   action is
defined in the task package that depends on this particular package.

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.

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

    >> Uhm, basically cdd-list would be wrapper around apt-cache, I'm
    >> not sure if it worths..
    Andreas> Well, id would be a wrapper around either apt-cache or
    Andreas> grep-dctrl or any other tool but it is definitely worth
    Andreas> the effort because you can do more than this command line
    Andreas> stuff.  What about a switch like

    Andreas>     -htmloutput (or -wmloutput)

    Andreas> to build web pages from installed / available <CDD>
    Andreas> packages for instance?  What about a -lang switch which
    Andreas> might work together with ddtp translated descriptions
    Andreas> (hopefully this will start working again)?  There are
    Andreas> several useful applications which gon into the field of
    Andreas> reasonable but easy to obtain documentation.

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.

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

    >> Yes that would definitively be the best option. But I'm
    >> assuming that it's difficult to go that way right now.

    Andreas> SUre.  If it would not be difficult it would be solved
    Andreas> 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.

    Andreas> I guess waiting is not enough.  We have to ask for it
    Andreas> frequently providing patches and reasonable suggestions.

I agree. I'd propose to start "bother" as soon as  we reach a somewhat
mature state  of the whole thing. I'm  confident  that this won't take
too long.

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

    Andreas> Feel free to fix cdd-gen-control in CVS ... ;-)

Ok, I'll write something as soon as I have a clearer picture.



Reply to: