The libebml package uses the deprecated `einstall` helper in src_install(), which seems to be incompatible with a Gentoo prefix. The first patch changes the ebuild to use `emake install DESTDIR="${ED}"` instead of `einstall`, per the development guide. The second patch changes the upstream Makefile to accept the DESTDIR parameter. Reproducible: Always Steps to Reproduce: $ cd /gentoo/usr/local/portage $ ecopy dev-libs/libebml $ emerge libebml Actual Results: * Aborting due to QA concerns: there are files installed outside the prefix $ emerge --info Portage 2.2.00.14771-prefix (prefix/sunos/solaris/5.11/x86, gcc-4.4.2, unavailable, 5.11 i86pc) ================================================================= System uname: Solaris-2.11-i86pc-i386-32bit-ELF Timestamp of tree: Fri, 06 Nov 2009 18:25:47 +0000 app-shells/bash: 4.0_p35 dev-lang/python: 2.6.2-r2 sys-devel/autoconf: 2.63-r01.1 sys-devel/automake: 1.10.2-r00.1, 1.11 sys-devel/binutils: 2.20.51.0.2 sys-devel/gcc-config: 1.4.1-r00.2 sys-devel/libtool: 2.2.6a-r00.2 ACCEPT_KEYWORDS="~x86-solaris" CBUILD="i386-pc-solaris2.11" CFLAGS="" CHOST="i386-pc-solaris2.11" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="" DISTDIR="/gentoo/usr/portage/distfiles" FEATURES="assume-digests collision-protect distlocks fixpackages news nostrip parallel-fetch preserve-libs protect-owned sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="en_US.UTF-8" LDFLAGS="" PKGDIR="/gentoo/usr/portage/packages" PORTAGE_CONFIGROOT="/gentoo/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/gentoo/var/tmp" PORTDIR="/gentoo/usr/portage" PORTDIR_OVERLAY="/gentoo/usr/local/portage" SYNC="rsync://rsync.prefix.freens.org/gentoo-portage-prefix" USE="cracklib modules ncurses prefix readline ssl x86-solaris zlib" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="SunOS" INPUT_DEVICES="keyboard mouse" KERNEL="SunOS" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, LINGUAS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 209457 [details, diff] libebml-0.7.8 patch: use `emake install` instead of `einstall`
Created attachment 209458 [details, diff] libebml-0.7.8 patch: change upstream Makefile to recognize DESTDIR
@video herd: the patch by Darik looks like an improvement to the libebml ebuild in general, are you ok with applying it in gx86?
(In reply to comment #3) > @video herd: the patch by Darik looks like an improvement to the libebml ebuild > in general, are you ok with applying it in gx86? No as it would break multilib-strict. Moreover this doesn't reflect DESTDIR semantics: it doesn't hurt here, but usually you have prefix=/usr and DESTDIR is used only when installing. In libebml's case, this would mean patching makefiles to have install calls like: $(INSTALL) $(INSTALL_DIR_OPTS) -d $(DESTDIR)$(includedir)
sorry, I didn't look closely enough to the patch
Created attachment 209949 [details, diff] libebml-0.7.8 patch: use `emake install` instead of `einstall`
Created attachment 209950 [details, diff] libebml-0.7.8 patch: change upstream Makefile to recognize DESTDIR
I read the multilib page and redid the patches according to the get_libdir example.
That looks more into the right direction. The emake install line should look like this (die omitted for brevity): emake DESTDIR="${D}" prefix="${EPREFIX}/usr" libdir="${EPREFIX}/usr/$(get_libdir)" install where preferably prefix and libdir have not to be set, but for that I need to check myself if this package uses configure, and if so, if it does so in the right way.
I get this error with that change: >>> Completed installing libebml-0.7.8-r1 into /gentoo/var/tmp/portage/dev-libs/libebml-0.7.8-r1/image/gentoo/ * QA Notice: gentoo///gentoo/ double prefix Is DESTDIR mandatory for Gentoo packaging? The bundled debian/rules script does the install like you suggest, but DESTDIR is unrecognized. This line gets a working result in a Solaris prefix without needing the DESTDIR patch: emake prefix="${EPREFIX}/usr" libdir="${EPREFIX}/usr/$(get_libdir)" install
> emake prefix="${EPREFIX}/usr" libdir="${EPREFIX}/usr/$(get_libdir)" install Nevermind this line, which is an unwholesome mistake.
Created attachment 209961 [details, diff] libebml-0.7.8 patch: use `emake install` instead of `einstall` > The emake install line should look like this You're right and I typo'd. The patch is refreshed again. (Sorry for the chatter.)
(In reply to comment #12) > Created an attachment (id=209961) [details] > libebml-0.7.8 patch: use `emake install` instead of `einstall` > > > The emake install line should look like this > > You're right and I typo'd. The patch is refreshed again. > > (Sorry for the chatter.) you cant drop the toolchain-funcs inherit like that, it's still used. we can't use EPREFIX in the main tree, can we?
(In reply to comment #13) > you cant drop the toolchain-funcs inherit like that, it's still used. > we can't use EPREFIX in the main tree, can we? you can
(In reply to comment #14) > (In reply to comment #13) > > you cant drop the toolchain-funcs inherit like that, it's still used. > > we can't use EPREFIX in the main tree, can we? > > you can > Fair enough, it ends up not hurting because it is unset I suppose. Once the toolchain-funcs inherit issue is fixed, feel free to apply it in the main tree, the patch seems sane. While patching the Makefile, you'd get extra cookies if you could fix bug #262973 meanwhile.
thanks this is in libebml-0.7.8-r2
