The attached patch is to make libesmtp work with prefixed portage. This patch is required by bug 195754. USE flags for testing: ssl -debug objective: `emerge esmtp` test system: x86-macos
Created attachment 133366 [details, diff] Patch to the libesmtp 1.0.4 ebuild to make it work with the prefixed portage
Created attachment 133389 [details, diff] patch against eapify'ed ebuild please diff against eapify'ed ebuilds (/usr/portage/scripts/eapify). please quote EPREFIX and use braces: $EPREFIX -> "${EPREFIX}" (that doesn't apply to this diff because EPREFIX is never used, but it applies to e.g. bug #195750 and i thought i might as well put that here) i've completely removed the libtool hack from the ebuild and it works for me. although i haven't investigated this, it's probably because gnu libtool was used when those lines were hacked in (no?) and it no longer is (we use the odcctools' libtool now). hence we wouldn't need to depend on libtool but the odcctools (which is obsolete because they're in 'system'). the libtool hack should be removed from the ebuild - not only in prefix but everywhere. I've gone ahead and removed it from the prefixified ebuild. (attaching a diff against the eupdated ebuild). not committing this for now because i'd like to hear grobian's opinion on this. a.) the hack doesn't do anything because no files are found - means we don't *have* to remove it - should we leave it in, keeping the diff down, and wait for semi-upstream to remove it? (i'd file a bug for that then), b.) what about the libtool dependency? ps: the way that hack was done is awful too. one should use `mv ${foo} ${foo%.so}.dylib` if necessary.
- if use ppc-macos; + if use ppc-macos || use x86-macos; Yeah... you're just dealing with one of my ultra dirty hacks of my ultra early days. pipping's patch looks much nicer, because that hack is unaccepptable any mroe. I'll remove it from the main tree.
in prefix[1]. [1] http://overlays.gentoo.org/proj/alt/changeset/11880
