Bugzilla Bug 37782

This was discussed on July 2003 on gentoo-dev, but the problem is still here,
however fix is trivial.

For now, it breaks GNOME in stable branch and opens potential security hole
while compiling applications using gettext. It also requires adding ugly hacks
to libtool (libtool-*-portage.patch).

Problem 1:
When einstall() is called, --libdir is changed to ${D}/usr/lib and --datadir is
changed to ${D}/usr/share. It causes recompiling or relinking in some projects
and causes invalid links to libraries in /var/tmp/portage (this is a bug and a
security hole) and some data files are then searched in /var/tmp/portage in run
time.

Problem 2:
econf() replaces --datadir with /usr/share. When einstall() is called --datadir
is changed to ${D}/usr/share but the depending PIXMAPS_DIR isnot changed to
${D}/usr/share/pixmaps cause it was written to the Makefiles in the configure
step before. It causes access violation during installation.

Alastair Tse wrote:
> Do the Makefiles use the variable DESTDIR? If they do, then use:
> make DESTDIR=${D} install || die "install failed"
> 
Yes, it is the correct and recommended solution! See "info automake" for more.

But einstall still uses ancient way:

                make prefix=${D}/usr \
                    datadir=${D}/usr/share \
                    infodir=${D}/usr/share/info \
                    localstatedir=${D}/var/lib \
                    mandir=${D}/usr/share/man \
                    sysconfdir=${D}/etc \
                    "$@" install

This way works for many packages and in past it was the only way, but it
is basically incorrect - those values has influence to compiler and
linker, not only for destination paths! This is the reason why automake
developers has added DESTDIR, which is designed to have no influence to
compiler.

Please change the default in portage and rename current einstall to
einstall_ancient.

Well, there are some bad projects, which installs OK with this ancient way,
but not with DESTDIR, but it's better to use autoreconf or write a fix.

There can be also reasonable work-around wrapper for all of them except
half-DESTDIR ones: Search for DESTDIR occurrence in all Makefiles.
If none is found, use einstall_ancient, otherwise use new einstall.

Why?

Changing prefix-based dirs is very dangerous way to install automake
based projects and can lead to access violation or even to mis-compiled
projects!

1) Many paths (e. g. PIXMAPS_DIR) are evaluated in configure time and
this install hack does not change it.

2) Purpose of all these variables is definition of default paths for
compiler and linker. If package recompiles/links something during
install process, it changes default path compiled into binary/library.

-----

Please make following a part of ebuild conventions:

Never use ${D} or /var/tmp/portage in following variables:
LDFLAGS, C*FLAGS

Strogly deprecated use of ${D} or /var/tmp/portage in following make variables:
prefix, exec_prefix, *dir

Variables designed for use ${D} or /var/tmp/portage:
LIBRARY_PATH, CPATH, C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, OBJC_INCLUDE_PATH,
DESTDIR

HOWTO:

Strongly deprecated is use of references to install root for prefix,
exec_prefix, bindir, sbindir, datadir, sysconfdir, localstatedir,
sharedstatedir, libexecdir, infodir, mandir, includedir, oldincludedir - use
DESTDIR instead. If application does not support DESTDIR (manually written
Makefile or Makefile generated by ancient version of automake), think twice
whether write a fix or use these variables. If you will use them, ensure that
no part of your project is relinked or recompiled in time of installation.

Do not use LDFLAGS and CPPFLAGS for references to install root - use
LIBRARY_PATH and CPATH (C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, OBJC_INCLUDE_PATH).
Otherwise you will get library with incorrect hardwired paths either to
binary/library or to la file. It is even security hole, if la file points to
/var/tmp.


Reproducible: Always
Steps to Reproduce:

This needs some general testing... as this will affect a GREAT
number of ebuilds quite quickly. Anyone care to give it a whirl?

I'll work on it with catalyst later, but people actually doing
live testing would be nice.

Created an attachment (id=23693) [details]
ebuild-destdir.diff

There is a patch with wrapper. I expect few access violations for some packages
half-conforming DESTDIR-style installation.

Second phase is to search for "make DESTDIR=${D} install" in all ebuilds and
replace it with einstall.

I am not sure, whether to keep wrapper forever or not.

Note I am not using single grep, because I expect large DESTDIR-style project
(where break occurs early) and small ancient style projects, where it is
required to search through all Makefiles.

i think we should keep 'einstall' as it is now, and just add the
einstall_destdir which does 'make DESTDIR="${D}" "$@" install'. There should be
no warnings displayed, and the choice of which one to use should be up to the
developer (and they should use einstall_destdir wherever possible).

I pretty much agree with #3. I doubt the initial gnome brokeness utx
encountered is because of the reasons mentioned in this bug alone, because of
the simple fact that we shouldve had much more reports over time.

That doesn't change the fact that it is probably better to move to using
DESTDIR as the favored method. Although i have seen no compelling statements in
the auto* docs that really make DESTDIR better than the current default method,
it is suggested use.

Gnome2 users can easily test the DESTDIR option, just set the USE_DESTDIR to 1
in gnome2.eclass locally. But those ebuilds probably won't show too much
problems, the real problems are going to be in the older ebuilds.

this discussion came up between azarah and myself sometime ago so i added to
the ebuild(5) manpage under einstall that you should always use 'make install
DESTDIR=${D}' instead of einstall if it works correctly

I have tested attached ebuild-destdir.diff wrapper patch in my current update.
Up to now I have found only one mis-installed package with access violations
(from about 100 tested) - nmap.

Is bug 34458 related to this?

*** Bug 50076 has been marked as a duplicate of this bug. ***

oz ~ # emerge info 
Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.4.4, glibc-2.3.5-r0, 
2.6.11-ck7-r1 i686) 
================================================================= 
System uname: 2.6.11-ck7-r1 i686 AMD Athlon(tm) XP 2200+ 
Gentoo Base System version 1.6.12 
Python:              
dev-lang/python-2.1.3-r1,dev-lang/python-2.4.1-r1,dev-lang/python-2.3.5,dev-lang/python-2.2.3-r5 
[2.4.1 (#1, Jun 17 2005, 23:05:02)] 
distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) 
[disabled] 
ccache version 2.3 [enabled] 
dev-lang/python:     2.1.3-r1, 2.4.1-r1, 2.3.5, 2.2.3-r5 
sys-apps/sandbox:    [Not Present] 
sys-devel/autoconf:  2.13, 2.59-r6 
sys-devel/automake:  1.7.9-r1, 1.8.5-r3, 1.5, 1.9.5, 1.6.3, 1.4_p6 
sys-devel/binutils:  2.15.92.0.2-r10 
sys-devel/libtool:   1.5.16 
virtual/os-headers:  2.6.8.1-r2 
ACCEPT_KEYWORDS="x86" 
AUTOCLEAN="yes" 
CFLAGS="-mtune=athlon-xp -march=athlon-xp -O3 -pipe -fomit-frame-pointer -mmmx 
-m3dnow -msse -mfpmath=sse,387" 
CHOST="i686-pc-linux-gnu" 
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" 
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" 
CXXFLAGS="-mtune=athlon-xp -march=athlon-xp -O3 -pipe -fomit-frame-pointer 
-mmmx -m3dnow -msse -mfpmath=sse,387" 
DISTDIR="/usr/portage/distfiles" 
FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict" 
GENTOO_MIRRORS="http://distfiles.gentoo.org 
http://distro.ibiblio.org/pub/Linux/distributions/gentoo" 
LDFLAGS="-Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common -s" 
LINGUAS="de en" 
MAKEOPTS="-j3" 
PKGDIR="/usr/portage/packages" 
PORTAGE_TMPDIR="/var/tmp" 
PORTDIR="/usr/portage" 
PORTDIR_OVERLAY="/usr/local/portage" 
SYNC="rsync://rsync.gentoo.org/gentoo-portage" 
USE="3dnow 3dnowex 3dnowext X a52 aalib alsa apache2 apm arts artswrappersuid 
audiofile avi bash-completion berkdb bidi bitmap-fonts bonobo cdparanoia cdr 
crypt cups curl dar64 dga divx4linux doc dvd dvdread eds emboss encode esd faad 
fam fbcon firebird flac foomaticdb fortran gatos gb gcj gd gdbm ggi gif gnome 
gphoto2 gpm gstreamer gtk gtk2 gtkhtml guile hal httpd imagemagick imlib jack 
java jpeg junit kde lcms libg++ libwww lirc live lzo mad matroska 
mfpmath=sse,387 mikmod mmx mmx2 mmxext motif mozilla mp3 mpeg mysql mythtv nas 
ncurses network nls nptl nptlonly nvidia odbc ogg oggvorbis opengl oss pam 
pdflib perl pic png ppds python qt quicktime readline real rtc samba sdl slang 
slp speex spell sse ssl stream svga tcltk tcpd tetex tiff truetype 
truetype-fonts type1-fonts usb v4l v4l2 vcd vorbis win32 wxwindows x86 xine 
xinerama xml xml2 xmms xosd xscreensaver xv xvid zlib linguas_de linguas_en 
userland_GNU kernel_linux elibc_glibc" 
Unset:  ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL 

(In reply to comment #5)
> this discussion came up between azarah and myself sometime ago so i added to 
the ebuild(5) manpage under einstall that you should always use 'make install 
DESTDIR=${D}' instead of einstall if it works correctly

So if that is the result, what is keeping this open?

nothing that i know of ...