Prev: mailing lists and "unknown mail transport error"
Next: How to accept email from unknown servers
From: Sahil Tandon on 5 Aug 2010 00:04
Jay G. Scott:
> what's the deal w/ no configure script?

There is no deal.

> if i supply a configure script, will you guys use it?

No.

> every time i try to go to a newer version of postfix, the
> installation overwrites the previous version. and that
> interferes w/ my system documentation. w/ a configure script
> i can install into a safe, stub directory w/o clobbering the
> existing files. then i can do a proper migration.

RTFM. In INSTALL, read:

4.4 - Overriding built-in parameter default settings

--
Sahil Tandon <sahil(a)FreeBSD.org>

From: Matt Hayes on 5 Aug 2010 00:07
On 08/04/2010 01:23 PM, Jay G. Scott wrote:
> what's the deal w/ no configure script?
>
> you do know that you DON'T NEED autoconf/automake to install, right?
> they're not hiding behind that old dodge, are they? i'm so sick of
> that.
>
> if i supply a configure script, will you guys use it?
>
> every time i try to go to a newer version of postfix, the
> installation overwrites the previous version. and that
> interferes w/ my system documentation. w/ a configure script
> i can install into a safe, stub directory w/o clobbering the
> existing files. then i can do a proper migration.
>
> j.



Strange, I can upgrade postfix versions using: make upgrade

No issues here.

-Matt

From: Roger Marquis on 5 Aug 2010 19:10
>> fine. but, c'mon. that's no reason to reinvent the wheel.
>> autoconf/automake do this in a way that's already
>> familiar to everyone. if you use the standard stuff
>> you save everybody grief.

One problem with that analogy is that not everyone is familiar with what
you think of as standard stuff. A simple "make install" is more standard
to many of us.

Another problem is library skew, aka DLL-hell. Postfix maintainers
should not have to be responsible for updates whenever the autoconf
version/API changes. It's bad enough when POSIX changes long-terms
standard shell features and command flags, add autoconf and the problem
increases 100 fold. Dependencies without a significant positive return
are rarely worth the trouble, especially when the scripts you would be
replacing are better than autoconf in the first place.

Also, many of us don't want to be restricted in our redistribution of
modified code. We particularly do not want to risk being sued by the FSF
for not publishing our own code because of some GPL dependency.

YMMV,
Roger Marquis

First  |  Prev  | 
Pages: 1 2 3
Prev: mailing lists and "unknown mail transport error"
Next: How to accept email from unknown servers