[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: exim4-config and exim4-base installed on systems with non-exim-MTA



* 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



Reply to: