Tore Anderson <[EMAIL PROTECTED]> 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/
