bug-gnu-libiconv
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gnu-libiconv] Error installing libiconv-1.13.1 on solaris 9


From: Claudio Fontana
Subject: Re: [bug-gnu-libiconv] Error installing libiconv-1.13.1 on solaris 9
Date: Wed, 25 Nov 2009 01:42:49 +0100
User-agent: Thunderbird 2.0.0.12 (X11/20080213)

Bruno Haible wrote:
Gene LeDuc wrote in 
<http://lists.gnu.org/archive/html/bug-gnu-libiconv/2009-11/msg00014.html>:
Modifying the prefix variable at install time, after a different prefix has
already been hardwired into the shared libraries and executables, is not
supported. (It is also not mentioned in the INSTALL.generic file.)
We've been using stow for many years to distribute binaries to our various servers and the way that I've found that works best is
   ./configure --prefix=/opt/local
   make
   make install prefix=/opt/local/software/packagename

The distribution package gets put into /opt/local/software/packagename and then stow links it into /opt/local, which is first in our executable search path. This works without any tweaking about 95% of the time. When it needs tweaking, it just involves moving subdirectories in the distribution tree up 2 levels.

I'll try DESTDIR, but it seems to me that I've tried it in the past and it didn't produce stowable results.

Claudio Fontana, the author of GNU sourceinstall, recently said that:
for some packages, setting the prefix for "make install" works;
for some packages, DESTDIR works; but none of the two methods works always.
It is here that GNU sourceinstall comes in and does it right always.
(At least that's what I understood. Claudio, please correct me if I got it
wrong.)

The DESTDIR is a dedicated concept: as far as I understand it has been
just introduced for exactly this purpose: staging installs for the
purpose of gathering information about the binary package, for both
sysadmin goals and packaging goals.

The prefix method I deem a hack in the sense that an existing concept
(prefix) is reused for a different purpose, sometimes not without
consequences, IIRC especially when other resources are involved (X11
resources, configuration files, etc), and the binaries of the staged
form do not correspond to the non-staged installation binaries anymore,
so they cannot simply be "moved in place" after information gathering,
and information gathering itself can be faulty.

In many simple cases it works as well. In some cases it does not and requires manual intervention afterwards, which defeats automatic tools.

Another problem is, there is little way to tell a priori whether a
package can be stage-installed using prefix redirection, since the
intention of the packager supporting --prefix is not primarily that of
providing the staged installation feature. Instead, seeing use of
DESTDIR shows an explicit intention to provide the feature.

From the point of view of tools trying to automate on top of the
existing conventions, DESTDIR seems preferable to me because it is a
dedicated concept, the 3 phases (configuration, compilation and
installation) can be identified clearly (no recompilation during
installation), it is clear which variables contribute to which phase,
and it is possible to draw a relationship between a configured package,
a compiled package, and its installed form.

Now sourceinstall, which is a tool that automates on top of GNU
conventions, uses DESTDIR first if it is available, but reverts to
prefix redirection if not (needs a confirmation after a warning
or --force on the cmdline).

It does not come in and do it right always, in the sense that
if the package wants to screw up, it certainly can,
however by giving priority to DESTDIR it tries to rely on the original
intent of the feature and of the packager himself.

In short: I would advocate using DESTDIR (correctly) to prepare a
package in order to be reliably stage-installed and advertise itself as
such.

The autotools already generate top-notch DESTDIR support, and its
correct functioning is checked at make distcheck time.

See http://www.gnu.org/software/automake/manual/automake.html#DESTDIR

Ciao,

Claudio








reply via email to

[Prev in Thread] Current Thread [Next in Thread]