Re: [Groff] [groff] 04/09: Fixes for `uninstall' target.

[Keith Marshall]

On 31/03/14 15:55, Werner LEMBERG wrote:
> 
>> 1) DESTDIR is fundamentally broken, for installations on MS-Windows
>> hosts; not a big deal, I guess, provided the user performing the
>> installation task is aware that they cannot use it.
> 
> Interesting.  I haven't used DESTDIR by myself, but I got requests to
> implement that for virtually everything.  Do you have a link
> explaining the reasons?

Well, you are welcome to trawl the archives of the MinGW-Users and
MinGW-Dvlpr mailing lists; IIRC, I may also have discussed the issue,
briefly, with Ralf Wildenhues, on the Autoconf list.  Alternatively, you
may wish to accept the following explanation:

1) The usage for DESTDIR, as stipulated in the GNU Coding Standards, is
in the form of references, in makefiles, such as

   $(DESTDIR)$(prefix)/some/installation/path
   $(DESTDIR)$(exec_prefix)/some/installation/path

2) The GCS forbids any makefile to define DESTDIR; that is exclusively
the prerogative of the user, when invoking make.

3) Both $(prefix) and $(exec_prefix), (which are often coincident),
*must* be defined as *absolute* paths; thus, on MS-Windows hosts, they
take the form

   prefix = D:/installation/root
   exec_prefix = D:/installation/root

(where D: represents an arbitrary, but necessary, device identifier).

4) The user specifies DESTDIR, at "make install" time, e.g.

   make install DESTDIR=staging/dir

On MS-Windows hosts, this results in *unconditionally* malformed paths,
in the form

   staging/dirD:/installation/root/some/installation/path

which is invalid; it can only ever be valid, if DESTDIR remains unspecified.

>> 2) Does DESTDIR have any real value, for an uninstall target?
> 
> IMHO yes.  It's good for testing purposes.

In the days before the GNU Standards Committee were persuaded to adopt
DESTDIR, the prescribed technique was to configure prefix, (and maybe
also exec_prefix), to point to a testing sandbox:

   ./configure --prefix=/path/to/sandbox ...

or to override them at "make install" time:

   make install prefix=/path/to/sandbox exec_prefix=/path/to/sandbox

This technique remains as viable today, as it always was, and it does
not require DESTDIR; it also has the advantage of working on MS-Windows
hosts, where DESTDIR is guaranteed to fail.

>> Its value lies in staging binary packages; "rm -rf ..." is the
>> simplest way to clear a staging tree, (unless multiple packages are
>> staged in a common tree, perhaps, and only one is to be selectively
>> discarded).
> 
> Well, `make install' should be the opposite of `make uninstall'
> *without moving stuff*.  It's an assymetry if installing with DESTDIR
> works, but uninstall doesn't.

Agreed, but it is an imposition on the user, to ensure that DESTDIR is
defined identically when invoking:

   make install DESTDIR=/path/to/sandbox

and subsequently:

   make uninstall DESTDIR=/path/to/sandbox

(Of course, the same is true of overriding prefix and/or exec_prefix at
"make install" time; the only way to completely avoid this issue is to
specify the /path/to/sandbox at "configure" time).

>> The concern is that DESTDIR is not preserved between install and
>> uninstall, placing an onus on the user to specify it identically on
>> both occasions.
> 
> AFAIK, the DESTDIR stuff is to build a package for a distribution;
> there are other means to install and uninstall packages.  So moving
> isn't a concern IMHO.

Oh, I'm well aware of the arguments in favour of DESTDIR; I just don't
buy them.  In reality, DESTDIR is a universally broken concept, IMHO.
It acquires value, only for distributors who create perversely arcane
installation structures, with the likes of $(docdir), for example,
relocated outside of the $(prefix) and/or $(exec_prefix) trees.

-- 
Regards,
Keith.