Re: Alternative to config-package-dev
On Tue, 23 Dec 2008, Olaf Mandel wrote:
Dear Debian mentors, dear maintainer of config-package-dev,
I like the idea of using configuration packages a lot (see
http://wiki.debian.org/ConfigPackages ). But I wanted more functionality
than config-package-dev provided, so I wrote my own collection of
scripts. My question is: what to do with it? I see the following
possibilities:
* Is there any interest in adding the new functionality to
config-package-dev (question is mostly for Mr. Abbott)?
* Should this be refined into a new package, with the executables in
/usr/bin and the debian/ template directory somewhere in /usr/share/ ?
* Would there be a prospective sponsor for such a package?
* Should this just be kept as a tar.bz2 referenced in some blog, i.e.
not added to Debian?
Hi Olaf,
Almost everything that your scripts support is already supported by
config-package-dev and standard debhelper/debian package features. It
sounds like the feature config-package-dev was missing is the debconf
preseeding feature for a configuration package (the installer script is
orthogonal to the configuration package implementation). I think your
implementation has some problems, but I'd be happy to discuss implementing
that feature correctly so that we can include it as a supported feature of
config-package-dev.
Your current implementation produces packages that don't comply with
Debian policy (e.g. the debconf stuff doesn't uninstall and upgrade
correctly), that would be confusing to people familiar with Debian
packaging (e.g. your use of "conflicts" and "depends" files to add entries
to debian/control), and that would be difficult to maintain as the
configuration package system improves.
I think that it is very important that a configuration package system
distributed by Debian generates packages that fully comply with Debian
policy, especially in relation to upgrade and removal. We have carefully
designed config-package-dev to integrate cleanly with the Debian packaging
system, as you can see from the examples at
<http://debathena.mit.edu/config-package-dev/#simple-examples>.
config-package-dev actually evolved from postinst and prerm scripts that
one copied into a package, similar to what you have created. We moved
away from that because any configuration package system that looks like a
bunch of files that are supposed to be copied into the debian/ directory
has maintenance problems. Whenever you improved the configuration package
system, you have to re-copy the files (making whatever minor changes were
needed to fit them to the package). We solved this problem by writing the
first version of config-package-dev.
I do think you will be better off using config-package-dev and CDBS to
configure your machines rather than writing your own scripts. You may
find the documentation at <http://debathena.mit.edu/config-package-dev/>
and <http://debathena.mit.edu/packaging/> helpful. If you run into any
problems doing so, feel free to contact me or the debathena@mit.edu
mailing list.
Below I have some additional technical thoughts on your system.
-Tim Abbott
I specifically did *not* use CDBS here to keep Build-Depends short,
though.
CDBS is required to build 16% of the packages in the Debian archive. I
don't think that avoiding a dependency on it is a useful goal. CDBS does
have somewhat of a learning curve, but once you have learned it, it can
save a huge amount of copy-and-paste in developing Debian packages.
A short introduction into the features of my script collection:
* Basically a "debian/" directory useful as a template to create a
configuration package with the following features:
** It depends on and conflicts with selectable other packages.
You should use the standard debian/control file for these declarations.
** It can preseed the debconf database.
This is a feature that I would like to have in config-package-dev. There
are at least two hard problems with doing this. One is making the package
uninstall and upgrade correctly. The other is setting up the installation
scripts so that installing the configuration package at the same time as
the package to be configured works correctly. Your scripts don't seem to
solve either of these problems.
** It contains arbitrary files.
I think you'd be better off using dh_install for this.
** Files can be configured to replace configuration files of other packages.
I think you would benefit from using config-package-dev for this purpose.
It has much better error handling than the divert-and-symlink code copied
from <http://wiki.debian.org/ConfigPackages>.
** It can run arbitrary scripts at the end of the postinst and the
beginning of the prerm stages.
The standard way to do this is to simply write a debian/postinst or
debian/prerm script which contains the #DEBHELPER# directive somewhere
within it. I recommend reading the dh_make templates to see how this is
done.
* Additionally, there is a template for an "installation script". This
is a single file that, when executed from a rescue-system, partitions
the hard drives, creates RAID, LUKS and LVM virtual devices, creates
filesystems, runs debootstrap and then installs a configuration package.
This can set up a working server in just a few minutes and is supposed
to be used for when a "normal" installation with the Debian installer is
not feasible (remote server with ssh-enabled rescue-system).
This seems like a useful capability that is independent of configuration
packages. At present I think your script makes too many site-specific
assumptions (e.g. the use of RAID) to be a good target for inclusion in
Debian.
It might be best in the long run to add support for ssh operation to the
Debian installer (if it doesn't already have it ...; I have heard that
there is an option in the installer's expert mode to move over to an sshd
after initial network configuration). You would use a preseed file to
make the installation process noninteractive; that has the advantage that
the installer already supports all the various installation-time
configuration options, and you'd just need to implement the ssh frontend.
You should bring the issue of ssh-enabled rescue systems up with the
Debian installer team if you can't figure out how to get it working.
Reply to: