Hello all,
I am at last working on our the *Distribution* of our CDD (better late than
never).
I've started to use the cdd-dev package and I have some comments and ideas I
want to share with everybody on the list.
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
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 ;).
Basically the current cdd-dev package supports the definition of
metapackages used to force or suggest the installation of other packages
(using Depends, Recommends and Suggests) and allows the inclusion of user
menus (for the debian menu system) and extra documentation.
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) and the extra documentation, if needed, will
be packaged separately and included as a dependency (currently we are using
an extra apt-source with special packages for branding, valencian l10n and
our own versions of some Packages that need changes to support our non
standard locale).
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
more than once on this list). The current cdd-dev package only supports
metapackages.
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
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.
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.
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).
- 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.
- If the task needs postconf scripts, those can be included into a
subdirectory called 'postconf', the idea is that the scripts will be
packaged into one or various .deb files (i.e. cdd-postconf_0.1_all.deb or
cdd-task-postconf_0.1_all.deb) and that will be installed with it's
task... if used from a custom debian-installer they can be called
automatically or they can be called by the local admininstrator using a
command like 'cdd-postconf CDD_NAME [CDD_TASK]'.
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.
Of course once this all this infrastructure is ready we will also need other
tools, but that's already being worked on (the debpartial-mirror rewrite
that Otavio Salvador is working on will probably be very useful to define
CDD only apt-sources and a future 'cdd-cdtool' will allow everybody to build
a specialized debian installer for their CDD).
Comments? Suggestions? Flames?
Greetings,
Sergio.
--
Sergio Talens-Oliag <sto@debian.org> <http://people.debian.org/~sto/>
Key fingerprint = 29DF 544F 1BD9 548C 8F15 86EF 6770 052B B8C1 FA69
Attachment:
signature.asc
Description: Digital signature