[Top][All Lists]

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

Re: Core-utils 7.2; building only 'su'

From: Bob Friesenhahn
Subject: Re: Core-utils 7.2; building only 'su'
Date: Wed, 15 Apr 2009 13:54:34 -0500 (CDT)

On Wed, 15 Apr 2009, Alfred M. Szmidt wrote:

  The problem is that DESTDIR is not a mandatory standard and
  packages may not adequately implement it even if Automake itself
  does the right thing.  If INSTALL says that DESTDIR is supported
  and a package blindly includes the INSTALL file, then package users
  may end up with a very unpleasant surprise (e.g. damaged operating
  system) if the package misbehaves with DESTDIR.

This is already the case for INSTALL.  For example, `make uninstall'
is often broken in many packages.  Same for --program-prefix.

The INSTALL file is probobly the best place to document this.

In the autotools world, some packages are more equal than others. Some packages are created via manual 'tar' of a source tree, others are created by 'make dist', while others are created via 'make distcheck'. If the package is created via 'make distcheck' then we have some confidence that DESTDIR and uninstall should work.

There are a lot of otherwise intelligent package developers who just can't seem to figure out how to properly use autotools, or just do a crappy job. As a result, many packages do not survive 'make distcheck', properly support DESTDIR, or know how to uninstall themselves.

If there was a way that a package could be "blessed" when it is created so that the user knows that this package is endowed by its creator with correct operation then end-users could know if DESTDIR is likely to work and that if they use 'make DESTDIR=/foo install' as root that it is not going to overwrite files outside of /foo.

Perhaps someone here can figure out how to apply this blessing so that it is possible for the end user to know if the package will follow the rules.

Bob Friesenhahn
GraphicsMagick Maintainer,

reply via email to

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