Re: Which packages a CDD is composed of? [Was: Integrating cdd-dev with dh-make]
>>>>> On Mon, 26 Apr 2004 16:04:26 +0200 (CEST), Andreas Tille <tillea@rki.de> said:
Andreas> [I think there is nothing private in this mail. sorry if
Andreas> I quote you in public but since April 2, the time where
Andreas> we keep CDD-mails in private is fortunately over. ;-)]
Andreas> On Mon, 26 Apr 2004, Free Ekanayaka wrote:
>> I meant that the cdd-addpackage script (or whatever we want to
>> name it), would just be a command line script to add a package
>> to a tasks/<TASK> file, which possibly checks whether a menu
>> file for such package is present in /usr/lib/menu and, if so,
>> copies it to the menu/ directory, maybe automatically replacing
>> the section= field according to the title of the task.
Andreas> Ahh, yes OK. But something remains unclear: Do you
Andreas> intend this to be done on the package developers machine
Andreas> who builds the task package or on the users machine who
Andreas> installs the task package?
The first you said, that means a possible work-flow of a CDD developer
would be:
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
# 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
Please note, that this just a rough idea. The goal would be to create
a simple interface to work with a source CDD package.
We may even decide that we do not need such additional scripts and
that we prefer manually editing the files.
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.
>> Yes, you're right. Task packages and relative custom menu files
>> have to go together. So let's drop the <CDD>-menu package, and
>> let's extend the task package definition with something like:
>>
>> 1) Task packages, named <CDD>-<TASK>. A task package depends
>> on all the packages that a CDD considers relevant for a
>> specific domain, and {must|is supposed to|should} provide
>> custom menu files for them, typically changing the hierarchy
>> structure or introducing ad hoc command line options . A
>> system administrator or a user can update the the menu
>> hierarchy by calling cdd-update-menus.
>>
>> We have to decide whether to allow packages without menu files
>> or not.
Andreas> We should allow this. Current implementation of
Andreas> cdd-install-helper throws a warning. Just try to build
Andreas> debian-med packages to verify this and see how it works.
Ok, fine for me. I'll try that.
>> Personally I would like to always see a menu entry, possibly
>> pointing to a man page in case of command line tools without a
>> GUI. This way we make sure that all the components of the CDD
>> are visible.
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> I can't comment on this because I do not know cfengine.
>> I didn't know it either before looking at the debian-edu-config
>> package. Now I found it wonderful. Please consider to have a
>> look at it.
Andreas> Sure. But currently I did not have a usage in the med-*
Andreas> packages.
I see. Anyhow probably even the cfengine configuration files should be
divided on per-task bases.
Since every cfengine action that a CDD defines is supposed to modify
some aspect of an installed package, perhaps it would make sense to
include the cfengine configuration file in which such action is
defined in the task package that depends on this particular package.
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.
* 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.
>> Uhm, basically cdd-list would be wrapper around apt-cache, I'm
>> not sure if it worths..
Andreas> Well, id would be a wrapper around either apt-cache or
Andreas> grep-dctrl or any other tool but it is definitely worth
Andreas> the effort because you can do more than this command line
Andreas> stuff. What about a switch like
Andreas> -htmloutput (or -wmloutput)
Andreas> to build web pages from installed / available <CDD>
Andreas> packages for instance? What about a -lang switch which
Andreas> might work together with ddtp translated descriptions
Andreas> (hopefully this will start working again)? There are
Andreas> several useful applications which gon into the field of
Andreas> reasonable but easy to obtain documentation.
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.
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>.
>> Yes that would definitively be the best option. But I'm
>> assuming that it's difficult to go that way right now.
Andreas> SUre. If it would not be difficult it would be solved
Andreas> right now.
>> Anyhow we can choose that tasksel is really what we want, push
>> for it and wait till we get the bug accepted and fixed.
Andreas> I guess waiting is not enough. We have to ask for it
Andreas> frequently providing patches and reasonable suggestions.
I agree. I'd propose to start "bother" as soon as we reach a somewhat
mature state of the whole thing. I'm confident that this won't take
too long.
>> As a temporary work around we can write a debhelper script
>> which automatically generates the debian/control entry for the
>> installation package. In the meantime we keep pushing for more
>> elegant solution.
Andreas> Feel free to fix cdd-gen-control in CVS ... ;-)
Ok, I'll write something as soon as I have a clearer picture.
bye,
free
Reply to: