Re: Which packages a CDD is composed of? [Was: Integrating cdd-dev with dh-make]
On Tue, 27 Apr 2004, Free Ekanayaka wrote:
> 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
What is the problem with
less /usr/share/doc/cdd-dev/examples/tasks/README
cp /usr/share/doc/cdd-dev/examples/tasks/task1 tasks/mytask
less /usr/share/doc/cdd-dev/examples/menu/README
cp /usr/share/doc/cdd-dev/examples/menu/task1 menu/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
vi tasks/mytask
vi menu/mytask
> Please note, that this just a rough idea. The goal would be to create
> a simple interface to work with a source CDD package.
Hmmm, I see no real point in creating an interface where a simple editor
could do the job.
> We may even decide that we do not need such additional scripts and
> that we prefer manually editing the files.
IMHO the effort to write such an interface is much to high if you keep in
mind that a developer has to have basic skills like reading REAME files
copying and editing templates.
> 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.
Well there are templates. I would say, I would not really like to use
CDD packages created by a person who is unable to work with these (perhaps
they could be enhanced and better documented, but that's all).
> 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?
Perhaps. The check would have to parse the "Depends:" line of
debian/control and verify that there is a valid menu file in
/etc/cdd/#CDD#/#role#/#CDD#-#task#
The #role# issue might cause roblems before we did a goof definition
what's reasonable here. Thus we should move such kind to low priotity
on the TODO list ...
> I see. Anyhow probably even the cfengine configuration files should be
> divided on per-task bases.
Probably. I see no reason for splitting.
> 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.
Menu is suggested or recommended.
> * 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.
Debconf and cfengine are optional.
> 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.
Sure. BUt it could be obtained from the same base of information.
> 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
> /usr/share/doc/<CDD>.
Perhaps. I more or less thought about keeping Debian websites up to date
or whatever. It should contain more general information and is not
necessarily intended for local documentation (even if this is no
contradiction).
Kind regards
Andreas.
Reply to: