On Wed, 1 Dec 2004, Sergio Talens-Oliag wrote:
I've found that the current system is probably OK for the CDD model used by debian-med, but I have the feeling that the model is not the one used/wanted
Well, it was adopted from debian-edu (debian-edu has some additional features I have to add) and also Debian-Jr would use it (see CVS).
in other Custom Distributions, at least I know I want to do more things and simplify the task as much as possible (I'm very lazy ;).
Me to. Lets share our lazyness. ;-)
From the current capabilities I only need the package selection, mainly because our CDD is not going to use the Debian Menu System (we are using only Gnome and .desktop files)
Well, it is not the fault of the menu system that gnome-panel has a bug which prevents displaying user menus ... :-((( I would love if this could be fixed soon!
I've built my metapackages using the current cdd-dev package and now I find that I need a lot of additional things and I don't like how the source package is stored and built.
The first thing I miss is more flexibility on the package selection mechanism; I only want to be able to declare which packages the user has to install for a given task, but I want to be able to do it using different systems (the use of tasksel and/or debtags instead of metapackages has been mentioned
I hope you used the cdd-dev package from experimental!!!! Please do development only for the expermiental package 0.3.9. It was uploaded to this place to wait for comments like yours before breaking anything. It has tasksel support. Feel free to add debtags support! (You remember my comment about lazyness?)
more than once on this list). The current cdd-dev package only supports metapackages.
NOOOOO. The packages in "sarge/sid" only support meta packages but you are not supposed to use thesie because I just do not want to make untested software its way into Sarge.
The second thing I miss is support for pre-seeding and postconfiguration of the packages included with a task; we have discussed a lot of times that
Sure. We discussed. Any volunteer to implement it????? If I were you I would start with the debian-edu packages and try to apply this scheme to the more general cdd-dev. Just start coding. I'm currently building GnuMed packages and I absolutely do not feel as the only person who should code for cdd-dev. I would be happy to include and test your work in Debian-Med packages!
almost all CDD need / want to be able to configure packages for our users using debconf (with pre-seeding for the normal debconf database and for the installer) and also provide some way to *postconfigure* the system once all the packages are installed (currently the proposal is to use cfengine, as debian-edu does). The current cdd-dev package does not address this issue at all.
It would be a nice Christmas gift...
So, what I plan to do? Well, I've been thinking about it and I believe we can fix those issues more or less easily using only one source package for each CDD that includes all of the above (package selections, presseding and postconf scripts) and generates the corresponding debs and udebs, using whatever technique the developer decides.
This is also my plan.
The idea is to modify the way the tasks are defined as follows:
- Each task is a subdirectory inside the tasks/ dir.
- The task dir contains a file for each valid field of the current task definition (I propose files because I feel it can be easier to parse and transform from shell scripts, but we can keep using one or more files with multiple fields inside).
The importat thing is to define formally which files, fields and formats are valid (required or optional) to be able to develop tools to transform the package selection they represent into different target formats: control files (for metapackages), *.desc files (for tasksel), tagfiles (for debtags) or even 'dpkg --set-seleccions' input files (we can select files to install or purge using simply that).
I could go with this perfectly. I just tried to adopt the Debian-Edu way to gain acceptance for cdd-dev. If you think you can convince these people who are IMHO the currently most advanced CDD (in terms of release and code) I'm happy to follow. That's the reason why I first went to experimental to not to switch interfaces too often.
Also the DeMuDi people (namely Free) had some trouble with the layout of the tasks directory. Just lets find a common agreement to enable us all to be lazy and just use common code.
- If the task needs to include preseeding for the debconf databases we will use the subdirectories 'preseed' and 'di-preseed' to store files with the preseeding (the idea is to use one file for each preseeded package, mainly for organizational purposes, but the tools that process the directories can concatenate all of them into one file for each task for distribution). The generated preseed files can be packaged into .udeb or .deb format and used with base-config.
Fine for me. What about the Debian-Edu people which just use pre seeding?
My idea is to start using this structure and build the tools I need as I go. Once I have everything prepared and tested I can include the tools into the cdd-dev package or develop a new package, depending on the opinions of the rest of developers.
I'd suggest to use SVN for this purpose to let others check out at the same time and test ist. (BTW, the SVN mails are not yet working again :-(()
Comments? Suggestions? Flames?
Everything is fine for me. Just start coding and document the changes which are relevant for other CDDs. Lets go for a common way to build our CDD stuff.
Good luck
Andreas.
-- http://fam-tille.de
