[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, Free Ekanayaka wrote:

> I think I  wasn't clear on  this. The cdd-addpackage script I proposed
> is not  meant to  be used  inside debian/rules,  but rather   from the
> command line or inside some other custom script.
Hmm, why not using debhelper scripts from debian/rules.  At least when
I was speaking about debhelper integration I wanted to say that I would
like to replace the cdd-install-helper which is called for instance to
replace dh_menu by a clean implementation which can act in debian/rules
working nice with and in the samer manner as debhelper script.

> I think  that before proceeding to  any actual development of  the cdd
> packages, we should state  clearly what a CDD is  in terms of packages
> that compose it.

> Every CDD  should have one single  package source, simply named <CDD>,
> which generates all the binary packages the CDD is composed of.
While I agree with this wholeheartly I guess we have to define some kind
of policy

> 1) Task  packages, named <CDD>-<TASK>.  These packages   which do not
>    provide any file, but simply depend on other packages.
> 2) A  menu package, named <CDD>-menu.   This package contains a set of
>    customised menu files.  Maybe these menu  files should be installed
>    in /usr/lib/<CDD>/menu or /usr/share/<CDD>/menu, rather than in the
>    current /etc/cdd/<CDD>/menu, as they are not properly config files.
>    A system administrator or a user can update the the menu hierarchy
>    bye calling cdd-update-menus.
Hmmm, currently it is solved a little bit different in Debian-Med and the
cdd- scripts are adopted to this.  IMHO, you proposal is not as practical
as it is done currently.  If you provide menus in a separate package it
has either to depend from all other packages or you will have some dangling
menu links.  The problem is that the menu correlates to the packages which
are installed by a certain task package and IMHO they belong to exactly
this package.  So I'd vote for inserting menus in the task packages (1).
If you need a common menu structure put these menus in 3).

> 3) A  common package,  named  <CDD>-common. This  package should  hold
>    common files, icons, themes, etc.
... common scripts, whatever is needed in the other packages, yes.

> 4) A debconf package, named <CDD>-debconf. This package contains a set
>    of debconf values, to  be injected in the debconf  db of the target
>    system.  Tools like  debconf-[get|set]-selections make  this pretty
>    easy to do.
Hmm, why not providing this also for every single task in (1)?  I guess you
will have debconf questions which are only relevant for a certain task.  Why
bothering users with questions which are irrelevant (because the task they
are related to is not installed)?

> 5) A cfengine package,  named   <CDD>-cfengine.  This  package  should
>    configure everything that <CDD>-debconf can't handle.
I can't comment on this because I do not know cfengine.

> 6) An installation  package,  simply named <CDD>. This  package barely
>    depends on  all the  above packages, so  that  you can install  the
>    whole <CDD> by issuing apt-get install <CDD>.
While I have no problems with this I had a different (perhaps additional)
approach in mind:  In


paragraph 6.2.1 I gave an overview about existing command line tools which
might be helpful for cdd handling.  The (depressing) resume is, that there
are no *really* helpfull tools available.  I habe some kind of tool in mind
which works like follows:

   ~> cdd-list <CDD>
   <CDD>-task1 - short description of task 1
    ... Output like
        apt-cache search <CDD> | grep '^<CDD>-'
   <CDD>-task<n> - short description of task <n>

   ~> cdd-list --short <CDD>
   <CDD>-task1 <CDD>-task2 <CDD>-task3 ... <CDD>-task<n>

   ~> cdd-list --long <CDD>
   ... Output of short and long description

If we would have such a tool, which could be easyly enhanced to do even more
practical stuff, we could just say:

   ~> apt-get install `cdd-list --short <CDD>`

and everything is fine.

A second approach is to make CDDs visible via tasksel (see paragraph 6.2.2
and file your comments to #186085 - it would really great if this bug could
have some input!!!).

Moreover we could file bug reports against aptitude and other user interfaces
to handle CDDs nicely which would make the use of a "main" cdd package unnecessary
(even if not useless).  So I'd suggest for the moment to go with such a main
package which depends from all tasks, but do not forget the other more elegant
solutions.  But please do not build this kind of package manually.  It should
be easy to patch cdd-gen-control to build the necessary entry in the debian/control
file automatically.

Kind regards


Reply to: