Which packages a CDD is composed of? [Was: Integrating cdd-dev with dh-make]
>>>>> On Sat, 24 Apr 2004 15:58:33 +0200, Cosimo Alfarano <kalfa@debian.org> said:
Cosimo> On Sat, Apr 24, 2004 at 10:28:02AM +0200, Free Ekanayaka
Cosimo> wrote: [...]
>> dh_make --templates /usr/share/debhelper/dh_make/debianc
Cosimo> [...]
>> NAME cdd-addtask - add a task file
Cosimo> [...]
>> It might seem a stupid but thing now, this way we if we want to
>> add features and tags to the task files, we have a better
>> framework.
Cosimo> I do not consider it stupid, a similar thing was in my
Cosimo> TODO list, I fully agree.
Good to hear this. Did you write this TODO list somewhere?
>> cdd-addpackage - add a package to a task file
Cosimo> [...]
>> Anyhow I'd like to underline that these are only rough
>> ideas. The main goal IMHO would be to have a more structured
>> way for creating and
Cosimo> We're in sync :) I had the same thoughts some days ago.
Cosimo> The main issue is the earliest we reach this goal the
Cosimo> nearest to a stable interface version we are. So the row
Cosimo> ideas should be enhanced towards concrete stuff, ASAP.
Cosimo> I do not think code is hard to write (that's bash :), the
Cosimo> only needing is produce a some sort of quite stable
Cosimo> version of it, at least for the interface used by CDDs:
Cosimo> how many script might be useful, how the user interacts
Cosimo> with them, etc. I thought something similar to dh_*
Cosimo> scripts using plain files in debian/ to read infos, with
Cosimo> the same schema, so they're easy to understand. So rather
Cosimo> then having cdd-addpackage, write all deps for task X to
Cosimo> debian/task-X.deps (the first name come to my mind).
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.
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.
I'll try to briefly describe what I have in mind.
Every CDD should have one single package source, simply named <CDD>,
which generates all the binary packages the CDD is composed of.
Typically these packages are:
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.
3) A common package, named <CDD>-common. This package should hold
common files, icons, themes, etc.
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.
5) A cfengine package, named <CDD>-cfengine. This package should
configure everything that <CDD>-debconf can't handle.
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>.
Of course this list might not be exhaustive, but I think it covers
most of the needs of a CDD.
Probably point 5) is the most delicate, because we have to find out a
way to modify other packages config files, which is compliant to the
Debian policy.
ciao,
free
Reply to: