Re: Feedback about the cdd-dev package and more...
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
Reply to: