* Marc Haber
> Well, I am only paid to work on the exim4 package if my employer gets
> to use the package as well. Since we don't want debconf questions to
> pop up during installation and we found the pre-fabricated -config too
> inflexible for our needs, -config needs to be split out.
So I take it you roll your own exim4-config-marchaber or something
which provides exim4-config?
If so, that does in no way explain the reasoning behind splitting
up the default configuration file in a million tiny files, nor why
simply creating a exim4-base-marchaber with the customized scheme
isn't adequate for you.
I'm glad to hear you're paid to work on Debian, as that certainly
makes it even more fun. :)
* Marc Haber
> and having the separate -config package allows people to throw away
> the entire -config magic.
* Tore Anderson
> How? (Short of creating a empty replacement -config package.)
* Marc Haber
> The source package holds infrastructure for three possibilities:
>
> - A script is included that splits out -config source from the source
> package, allowing the debconf stuff to be modified independently
> - A script is included that creates a debconf-less -config source
> package that uses split config.
> - A script is included that creates a -config source package with
> monolithic config.
In other words, «people» must be familiar with the process of building
Debian packages, and must be willing to spend time learning this Debian-
specific infrastructure to be able to manage their Exim installation in
a generic and non-Debian-specific manner. I don't really see that as
being advantageous to a more than a select few users.
Furthermore, I still don't see the reasoning behind and/or advantages
incurred by splitting off the exim4-config package and splitting the
config file into all those tiny conf.d-snippets.
I would suggest something like this:
- A exim4-base package containing the default debconf scripts,
which installs a (monolithic) configuration file.
- The source package could then, to cater for power users such as
yourself, contain scripts to
1) split out the -base source from the source package, allowing
the debconf stuff to be modified independently, and
2) create a debconf-less -base source package that uses
monolithic config, and possibly
3) create a debconf-less -base source package that uses
split config, and possibly
4) create a -base source package that uses split config.
- exim4-daemon-whatever declares a dependency on
exim4-base-custom | exim4-base, or exim4-base-custom declares a
provides for exim4-base.
- exim4-daemon-whatever declares a provides for exim4-daemon, and
exim4-base[-custom] declares a depends on this virtual package.
What point have I missed that makes this inferior to the way the Exim
packages are currently structured?
As an added bonus, implementing this will also make the problem you
initially inquired about go away.
--
Tore Anderson
