On Mon, Jan 08, 2001 at 03:33:48PM +0000, [EMAIL PROTECTED] wrote:
> On Mon, Jan 08, 2001 at 10:16:22AM -0500, Alex Pennace wrote:
> > I don't see what the problem is. If you really want smtproutes handled
> > like it is now, make a symlink from mailroutes to smtproutes.
>
> A symlink get's the job done, granted. But I would prefer that the patch
> doesn't change the current smtproutes behaviour if we can.
>
> Image this:
> - i have a stock qmail server with a smtproutes;
> - i decide that I want to use qmtp with mxps
> - i patch qmail with Russell's or Johan patch
> - suddenly, my smtproutes stop working... because I forgot to rename
> the smtproutes file.
Or imagine:
- I have a stock qmail server with smtproutes,
- I decide that I want to use QMTP,
- I setup an appropriate mailroutes file,
- It doesn't work, because I forgot to patch qmail.
> Why? Is is that much trouble to have Johan patch read smtproutes first
> and then mailroutes (or qmtproutes), and giving precedence to the
> first?
Why give smtproutes priority? If mailroutes doesn't exist than
smtproutes will be used anyway, if smtproutes support is kept.
> It gives you a clean upgrade path , and doesn't force you to
> change the configuratio (mv smtproutes mailroutes) just because you
> patched qmail...
Why must every outdated configuration be supported because some people
can reconcile using patch -p1 < johans-patch but can't reconcile mv
onecontrolfile anothercontrolfile? People should be following
directions in README, INSTALL, and UPGRADE.
> My view: patches should add funcionality. They should make their best
> not to force changes on a working situation.
Patches always change a working situation, by definition.
