Richard Coleman <[EMAIL PROTECTED]> writes:
> After a little over two years of hacking on nmh, I'm proud to announce
> the release of version 1.0. I figured that after this length of time,
> the version number should be bumped to better reflected its current
> stability.
Congrats, Richard.
I have one complaint about the installation process, however, that I
reported a few versions ago but is still not fixed.
I always install software packages "inline" -- that is, instead of having
files be installed directly in directories off of /usr/local, I have them
installed in directories off the main source directory. I then make
symbolic links in /usr/local to the real location of the files. This makes
it easy to see what /usr/local files came from where, prevents one package
from overwriting a file that another package installed, and makes it easy to
switch the "public" version of a package back and forth between multiple
configured versions.
With nmh-0.22 and previous versions, it was possible to do something like
this:
% cd /usr/local
% zcat ~/sw/Mail/mh/nmh-0.22.tar.gz | tar xvf -
% cd nmh-0.22
--> % configure --prefix=$cwd
% make
% make install
The next version of nmh I installed was nmh-0.28-pre7, and this no longer
worked because the files in the installation "etc" directory are mv'd to
*.old before the files in the source "etc" directory are copied into the
installation directory. If the source and installation directory are the
same, however, the source files no longer exist, so the copies fail.
There would be several ways to fix this -- you could cp -p the files instead
of mv'ing them, or you could detect that the source and installation "etc"
directories are the same and not do anything. Not sure what nmh-0.22 and
previous versions did, but whatever it was, it worked.
The workaround, of course, is to do something like:
% configure --prefix=$cwd/install
but it would be nice if the configuration process at least detected when you
are trying to do an inline installation and warn you that it's not going to
work properly.
I think this is the same stuff I said last time I complained about this.
---------------------------------------------------------------
Dan Harkless | To prevent SPAM contamination, please
[EMAIL PROTECTED] | do not post this private email address
Unitech Research, Inc. | to the USENET or WWW. Thank you.
