From: Wietse Venema on
Jay G. Scott:
> every time i try to go to a newer version of postfix, the
> installation overwrites the previous version. and that

You can choose the install location.

Wietse

From: Kenneth Marshall on
On Wed, Aug 04, 2010 at 01:40:29PM -0400, Brian Evans - Postfix List wrote:
> On 8/4/2010 1: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.
> The Postfix build system can already take this into account.
>
> For example, Gentoo Linux sandboxes all builds in case something fails.
> As part of this build system, it uses the following documented switches to
> CCARGS in "make makefiles"
>
> mycc="${mycc} -DDEF_DAEMON_DIR=\\\"/usr/$(get_libdir)/postfix\\\""
> mycc="${mycc} -DDEF_MANPAGE_DIR=\\\"/usr/share/man\\\""
> mycc="${mycc} -DDEF_README_DIR=\\\"/usr/share/doc/${PF}/readme\\\""
> mycc="${mycc} -DDEF_HTML_DIR=\\\"/usr/share/doc/${PF}/html\\\""
>
> This is only a sample of what can be built. More can be found here:
> http://www.postfix.org/INSTALL.html
>
> The postfix-install script respects install_root to sandbox a new install
> that can be moved later.
>
>
Yes, that is what we use here.

Ken

From: Kenneth Marshall on
On Wed, Aug 04, 2010 at 12:50:36PM -0500, Jay G. Scott wrote:
> On Wed, Aug 04, 2010 at 01:40:29PM -0400, Brian Evans - Postfix List wrote:
> > On 8/4/2010 1: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.
> > The Postfix build system can already take this into account.
>
> 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. this one-off method isn't easier.
> or if it is, it's time to package this method and replace
> autoconf/automake.
>

Having been stuck in autoconf/automake purgatory where due to
version requirements and bugs in various versions I ended up
manually having to touch all of my Makefiles to get a working
build, I appreciate something aimed at the lowest common
build requirements. I have built and installed postfix on
embarrassingly ancient/ill-equiped systems in less time than
it would have taken to download autoconf/..., much less build
or port it if a package was not available.

Cheers,
Ken

From: Phil Howard on
On Wed, Aug 4, 2010 at 13:23, Jay G. Scott <gl(a)arlut.utexas.edu> 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.

Install on a new migration machine on which you can do proper testing
before making the switch. Be sure this new migration machine also has
the latest version of your favorite OS, as well as latest version of
related software (your IMAP server, your DB engine, etc). Move test
domains to this server first and make sure it works. Then somewhat
before the appointed time, move all the data to the new machine. Then
synchronize it one more time at the last moment and stop email on the
old machine. Bring up email on the new machine and run all your tests
again with the primary domain(s). If something doesn't work, shutdown
and move back. Whether you "move" by IP address or DNS changes or
swapping hard drives is your choice. There are a number of ways to do
this. But I don't know anyone who would just up and install a new
software version on top of an existing server. So I would not imagine
Postfix making any effort to support such a thing. I could be wrong,
but I wouldn't make any effort to have a software package support it.
I've done the two machine migration approach for 30 years.

But if you really insist on doing it all on one machine, might I
suggest a chroot tree copy, or a virtual machine?

--
sHiFt HaPpEnS!

From: Peter Evans on
On Wed, Aug 04, 2010 at 12:23:13PM -0500, Jay G. Scott wrote:
> what's the deal w/ no configure script?

Personally, I hate them. If you wanted to backdoor something,
backdooring the configure script would be an excellent way in.
No one checks the thousands of lines of baroque shellscript trying
to find out if you have Fortran, five flavours of gcc, et al.

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

Sorry, no. Nothing personal you understand.

autoconfigure stuff gives me nightmares. Especially code like
asterisk, where no matter what you tell it, it will insist on
using gcc for some bits, and your sun compiler for other bits,
but accidentally leave in the gcc compiler options like -Winane-message


> 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.

I think you would confuse yourself with N versions thereof.

As for directory, read the INSTALL file. Section 4.4

4.4 - Overriding built-in parameter default settings


This is the section Wietse is intimating in his mail elsewhere in this
thread.


p