Re: Which packages a CDD is composed of? [Was: Integrating cdd-dev with dh-make]
>>>>> On Tue, 27 Apr 2004 19:00:46 +0200 (CEST), Andreas Tille <email@example.com> said:
Andreas> On Tue, 27 Apr 2004, Free Ekanayaka wrote:
>> 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..
Andreas> Sure. Tell just create an Alioth account and I'll add
Andreas> you to the developers list there. We should have at
Andreas> least one of each CDD with write access in the project.
Andreas> Then you can do what you like. ;-)
I thought I already had an account, even if it is a guest one
(free-guest). I was even able to commit some typos I fixed..
Do I need to get a "ordinary" (as opposed to guest) account?
>> |_ debian/
>> |_ tasks/
>> |_ common/
>> | |
>> | |_ README | |_ control | |_ conf
Andreas> While thos is not a big matter I would vote for the
Andreas> layout I have choosen for debian-med. Common resides in
Andreas> the main directory because it is different in terms of
Andreas> structure from the other packages. Please have a look at
Andreas> debian-med source. It is released and works.
Yes, this package is actually different from the other ones. I was
think to this too after having sent my previous email.
Let's keep in a separate directory, as you outline.
>> | |_ task1/
>> |_ README |_ [*.]control |_ [*.]menu |_ [*.]debconf |_
>> [*.]cfengine |_ ...
Andreas> This is probably better than my approach because I
Andreas> splitted menu from the tasks dir which might not be the
Andreas> best idea ...
>> 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).
Andreas> While I see it similar, debian-edu works without common
Andreas> package. BUt this might change.
Yes, I'll not die if we won't use the common package, or if we call it
in another way or modify it. I just say let's talk about it.
IMHO the key aspect of the common package is to provide a way to
choose on which users the customisation (menu, configs or whatever)
should take effect, and I this is need of all CDDs.
Anyhow if we agree at least on the tasks/ structure, I can
modify/write the code as necessary. I think I can do it in the next
>> 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
>> 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.
Andreas> Perhaps you might read the *.txt files of debian-med and
Andreas> tell me what you think about it.
Yes, I didn't :/ I'll report on this..
>> 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?).
Andreas> I'm not completely settled my mind in this question.
I mean, the whole point is to generate the documentation from the
tasks/ hierarchy, isn't it? Then we provide a package with this
documentation (e.g. mycdd-doc) and everybody can do what he wants with