Christoph Martin wrote:
>> 1) The debconf template mimedefang/embedperl asks the admin whether
>> MIMEDefang should use the embedded Perl interpreter (defaulting
>> to "true"), but there's no package dependency on eperl.
[...]
>
> eperl is not the same as embeded perl. You don't need a different perl
> package to use mimedefang with the embedded perl feature. You just have
> to call mimedefang in a different way to make it to make it reuse the
> same perl interpreter for new mimedefang request instead of calling a
> perl process for each instance etc.
Unfortunately this means that the version of the template that
translators are now working on (bug #461013) is wrong. The line:
_Description: Should MIMEDefang use the embedded Perl interpreter?
should have been corrected to something more like:
_Description: Should MIMEDefang use its own Perl interpreter?
Would you consider also adding a mimedefang-multiplexor(8) pointer
for the benefit of those reading the template who happen not to have
read its useful section on the pros and cons of EMBEDDING PERL?
[...]
>> Are there in fact other ways of using MIMEDefang that don't involve
>> (locally installed) Sendmail, or should it be a Depends?
>
> The milter interfaces allows you to call the filter processes via
> different ways of communication. The default ist to use a unix socket,
> but you can use a tcp socket instead. This enables you to put the filter
> process on a different machine alltogether. This is why there is no hard
> depends on sendmail for mimedefang.
Fair enough; possible but inadvisable ("Use inet_any with
caution!"). In that case it makes perfect sense *not* to advertise
it in the package description.
--
JBR
Ankh kak! (Ancient Egyptian blessing)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
