[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



Tore Anderson <tore@linpro.no> wrote:
> * Marc Haber

> > Splitting up the config file in small files was necessary to do
> > debconf support, which is a Debian requirement.

>  Debconf support is now required?  I'm flabbergasted.  Could you
> please point me to this section of our policy?  I certainly cannot
> find it.
[...]

3.10.1. No it is not "required" but "Prompting the user by other means,
such as by hand[7], is now deprecated." The alternative is shipping
a dpkg-conffile /etc/exim4/exim4.conf that _only_ does local delivery
(That is the only safe default.) and tell people to use $editor.

[...]
> > Please state how you intend to fulfill policy with that approach. Give
> > code examples.

>  An existing code example from the top of my head would be the current
> xserver-xfree86 package's config and postinst scripts.  Another package
> which does much of the same thing, albeit in quite a different manner,
> is proftpd.  I'm sure there's many more.

>  Would you and Andreas seriously consider modifying the Exim packages
> to the layout I suggested in my former post?  If so, I would be happy
> to spend some time developing a patch for this purpose.

No, I am sorry (and thanks for the offer). You effectively proposed
repacking from scratch, which requires amounts of work and testing I
am not willing to invest. - I would need to hand the package over to
you.

If you think conf.d sucks like hell (where did I get this idea from? ;-)
try providing a patch for exim4-config-sane, which supports:
* debconf
* propagating changes in our exim4.conf (e.g. changed options for a
  transport) to the user on upgrade. I.e. dpkg-like conffile
  managment. That is the part where exim(v3) failed.
* no additional maintainance work i.e. it would need to base its
  config on the conf.d snippets in CVS. If I fix the AUTH
  examples in conf.d I don't want to duplicate the work. i.e.

An implementation would generate exim4.conf.example at build-time from
the conf.d snippets
  find conf.d/ -path '*/CVS/*' -prune -or -type f -print0 | \
             xargs -0 cat > exim4.conf.example.
and at installation would ask debconf-questions and generate a
exim4.conf from exim4.conf.example by filling in the anwers and use
ucf[1] to manage it.

As you can see I have rather well formed opinion on how the package
would need to work.

If exim4-config-sane worked well we could switch priorities and make _it_
important instead of of exim4-config.[3]

Pros and cons:
[ I'll explain in fup-message]

Don't start implementing yet, there is more to come.
                      cu andreas

[1] or essentially a private copy or reimplentation of it.
[2] Or simply do without making separate packages, making conf.d
yes/no a medium debconf-question.
-- 
Hey, da ist ein Ballonautomat auf der Toilette!
Unofficial _Debian-packages_ of latest unstable _tin_
http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/



Reply to: