The eautoreconf in the ebuild fails with the following: ***** automake ***** ***** PWD: /var/tmp/paludis/dev-libs-redland-1.0.9/work/redland-1.0.9 ***** automake --add-missing --copy src/Makefile.am:26: Libtool library used but `LIBTOOL' is undefined src/Makefile.am:26: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/Makefile.am:26: to `configure.ac' and run `aclocal' and `autoconf' again. src/Makefile.am:26: If `AC_PROG_LIBTOOL' is in `configure.ac', make sure src/Makefile.am:26: its definition is in aclocal's search path. If I do as it suggests and add AC_PROG_LIBTOOL, eautoreconf succeeds but configure fails with ./configure: line 20522: syntax error near unexpected token `libltdl' ./configure: line 20522: `LT_CONFIG_LTDL_DIR(libltdl)' The LT_CONFIG_LTDL_DIR macro was introduced in libtool 2: snipped from the NEWS file: New in 2.1b: 2008-02-01; CVS version 2.1a, Libtool team: * New features: - New LT_CONFIG_LTDL_DIR macro to specify a different directory name for a convenience libltdl. Therefore, the ebuild needs a dependency on libtool 2 (unless someone feels like making it not need to use that macro). I'm not sure why the original eautoreconf failure doesn't occur for everyone - it might be an automake version issue, but I don't feel like messing with ~arch autotools on my system right now.... In any case, it's probably best to add the macro, it suggests.
Created attachment 199221 [details, diff] redland-1.0.9-ldflags.patch This incorporates and replaces the existing patch, and adds the macro that automake complains about.
That failure is due to you mixing stable and unstable. redland has following line in configure.ac: LT_INIT([dlopen]) That's how main libtool macro is called in libtool 2 (AC_PROG_LIBTOOL is just a legacy name there). Yes, libtool 2 is quite long overdue for stable, but that's another matter. Anyway, that means in unstable things work. Shall redland 1.0.9 go stable before libtool 2 (quite possible), this will become a problem, not before.
Comment on attachment 199221 [details, diff] redland-1.0.9-ldflags.patch OK, then there's no need to change the patch. However, versioned dependencies exist for a reason - if the package needs libtool 2, then it should depend on libtool 2. If nothing else, it allows repoman to ensure that this version of redland doesn't go stable until libtool 2 does. As for mixing stable and unstable, the fact is that people do it. One can't expect it to work perfectly all the time, but there's no reason not to fix known issues, if the fix is as simple as adding a dependency.
redland 1.0.9 isn't even in ~arch, it's package.masked
+ 27 Jul 2009; Samuli Suominen <ssuominen@gentoo.org> redland-1.0.9.ebuild: + Remove call to elibtoolize since we call eautoreconf and force >=libtool-2 + wrt #279178. +