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.
Sure.
> 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
http://people.debian.org/~tille/debian-med/talks/paper-cdd/debian-cdd.html/ch-technology.en.html#s-mp_handling
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
Andreas.
Reply to: