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

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 <tillea@rki.de> 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
    >> cdd-install-cfengine

    Andreas> OK.

    >> 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?

    Andreas> Yes.

    >> 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



Reply to: