[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.



Reply to: