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 attachment 23693 [details, diff] 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 ...
