Re: Which packages a CDD is composed of? [Was: Integrating cdd-dev with dh-make]
>>>>> On Tue, 27 Apr 2004 11:32:17 +0200 (CEST), Andreas Tille <tillea@rki.de> said:
Andreas> 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
Andreas> What is the problem with
Andreas> less /usr/share/doc/cdd-dev/examples/tasks/README cp
Andreas> /usr/share/doc/cdd-dev/examples/tasks/task1 tasks/mytask
Andreas> less /usr/share/doc/cdd-dev/examples/menu/README cp
Andreas> /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
Andreas> 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.
Andreas> Hmmm, I see no real point in creating an interface where
Andreas> 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.
Andreas> IMHO the effort to write such an interface is much to
Andreas> high if you keep in mind that a developer has to have
Andreas> basic skills like reading REAME files copying and editing
Andreas> 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.
Andreas> Well there are templates. I would say, I would not
Andreas> really like to use CDD packages created by a person who
Andreas> is unable to work with these (perhaps they could be
Andreas> enhanced and better documented, but that's all).
Ok, I understand all your arguments, which are the same doubts I had
myself. So, fine for me, let's drop this..
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?
Andreas> Perhaps. The check would have to parse the "Depends:"
Andreas> line of debian/control and verify that there is a valid
Andreas> menu file in /etc/cdd/#CDD#/#role#/#CDD#-#task# The
Andreas> #role# issue might cause roblems before we did a goof
Andreas> definition what's reasonable here. Thus we should move
Andreas> such kind to low priotity on the TODO list ...
Ok, is there a way to open Feature Request and ToDo trackers on
Alioth, as an ordinary GForge site? I find GForge trackers very
useful..
>> I see. Anyhow probably even the cfengine configuration files
>> should be divided on per-task bases.
Andreas> Probably. I see no reason for splitting.
Ok.
>> 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.
Andreas> Menu is suggested or recommended.
Yes.
>> * 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.
Andreas> Debconf and cfengine are optional.
Yes.
So, to summarise the whole thing, it turned out that the bricks of a
CDD are task packages, that, besides mere dependencies, provide
various types additional information for the packages they depend on.
Currently these types are menu (recommended), debconf (optional) and
cfengine (optional), but new needs may arise in the future.
I'd suggest to change the structure of the CDD source packages to
reflect more cleanly this concept of task with attached information.
What do you think about something like:
mycdd-0.1/
|
|_ debian/
|
|_ tasks/
|
|_ common/
| |
| |_ README
| |_ control
| |_ conf
|
|_ task1/
|
|_ README
|_ [*.]control
|_ [*.]menu
|_ [*.]debconf
|_ [*.]cfengine
|_ ...
where [*.] means that files can optionally be splitted in sub1.menu,
sub2.menu or sub1.cfengine, sub2.cfengine, if files get to big.
The "common" task is mandatory, because it provides it registers the
CDD in /etc/cdd, provides role support (it might extend its
functionalities in future).
The "control" files are equivalent to the former tasks/* files.
Then debhelper like scripts take care of properly handle the various
information, installing files and possibly adding chunks of code to
the postinst and postrm scripts:
cdd-gen-control
cdd-install-menu
cdd-install-debconf
cdd-install-cfengine
Finally I've read that cdd-install-helper currently scans the docs/
directory for .txt files. If understand correctly these .txt files
should be written in case a given package has no menu entry, isn't it?
In this case I think that we should either file a bug against the
package which doesn't provide the menu file, or generate a menu entry
which displays the man page of such package, rather then an home made
.txt file. If even the manual page is present, then this is a serious
bug of the package and we should try to write it and send it to the
maintainer.
>> 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.
Andreas> Sure. BUt it could be obtained from the same base of
Andreas> information.
Yes, all the need information would be contained in the task/
hierarchy.
>> 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>.
Andreas> Perhaps. I more or less thought about keeping Debian
Andreas> websites up to date or whatever. It should contain more
Andreas> general information and is not necessarily intended for
Andreas> local documentation (even if this is no contradiction).
I think that debian website can simply use the files contained in,
let's say, mycdd-doc, which contains documentation in various formats
(i.e. suitable for various type of display) and is generated by a
debhelper script (cdd-install-doc?).
Simply my 2 cents..
Free Ekanayaka
Reply to: