When package- (not ebuild-) maintainers do their packaging on some Gentoo Linux (or Prefix) using /usr/bin/libtoolize, the resulting package is shipped with copies of (very likely) gentoo specific /usr/share/libtool/ltmain.sh and /usr/share/aclocal/libtool.m4 (as part of configure). This results in bug-reports like: http://lists.gnu.org/archive/html/bug-libtool/2007-08/msg00002.html http://lists.gnu.org/archive/html/bug-libtool/2005-12/msg00014.html And I'm pretty sure these are just the tip of the iceberg of user headaches on various non-Gentoo platforms. OTOH, /usr/bin/libtool itself must be created _with_ (gentoo-specific) patches, especially in Prefix, so it can be used (via PATH) to _build_ packages that do not use libtoolize and therefore are not shipped with bundled libtool (ncurses fex, on AIX). IMO, the only allowed patches applied to /usr/share/aclocal/libtool.m4 and /usr/share/libtool/ltmain.sh - if any - should be upstream-accepted ones. Yes, there is USE=vanilla, but gentoo users seldom will have done this: $ echo "sys-devel/libtool vanilla" >> /etc/portage/package.use Currently, this also would break /usr/bin/libtool on various prefix platforms. Instead, any necessary (gentoo-/prefix-specific) libtool-patching should be done within elibtoolize only. Additionally, libtool.ebuild also should use elibtoolize, to install a working /usr/bin/libtool (in Prefix), while preserving vanilla (or with upstream- accepted patches applied only) ltmain.sh (and libtool.m4) for /usr/bin/libtoolize. Yes, vanilla libtool does not fully work yet on each platform currently found in Prefix (and others), but we should not have package maintainers to ship their packages with gentoo-specific libtool cruft, even if it fixes issues on their platform, as we cannot guarantee such fixes don't break other platforms. As a consequence, useflag 'vanilla' should be dropped from libtool.ebuild.
the patches written for libtool attempt to be clean and usable on all systems, and this policy will continue. historically there have been some that werent so clean, but i'm not going to change libtool-1.x now that libtool-2.x is in the tree without the patches in question.
