The following ebuilds/eclasses are using the almost deprecated gnuconfig_update function from gnuconfig.eclass: ./sys-libs/db/db-3.2.9-r10.ebuild: gnuconfig_update ./sys-libs/db/db-4.0.14-r2.ebuild: gnuconfig_update ./sys-libs/db/db-4.0.14-r3.ebuild: gnuconfig_update ./sys-libs/db/db-4.1.25_p1-r3.ebuild: gnuconfig_update "${S}/../dist" ./sys-libs/db/db-4.1.25_p1-r4.ebuild: gnuconfig_update "${S}/../dist" ./sys-libs/db/db-4.1.25_p2.ebuild: gnuconfig_update "${S}/../dist" ./sys-libs/db/db-4.2.52_p2-r1.ebuild: gnuconfig_update "${S}/../dist" ./sys-libs/db/db-4.2.52_p2.ebuild: gnuconfig_update "${S}/../dist" ./sys-libs/db/db-4.2.52_p4.ebuild: gnuconfig_update "${S}/../dist" ./sys-libs/db/db-4.3.27.ebuild: gnuconfig_update "${S}/../dist" ./sys-libs/db/db-4.3.29.ebuild: gnuconfig_update "${S}/../dist" ./sys-libs/db/db-4.4.20_p2.ebuild: gnuconfig_update "${S}"/../dist ./sys-libs/db/db-4.2.52_p4-r2.ebuild: gnuconfig_update "${S}"/../dist ./sys-libs/db/db-4.3.29-r2.ebuild: gnuconfig_update "${S}"/../dist ./sys-libs/db/db-3.2.9-r11.ebuild: gnuconfig_update This might be due by various reasons, and some of them cannot be worked around at the current time, so please find your case in the following list: * the ebuild does not use econf, but ./configure, because it uses a very old version of autoconf that does not support the parameters we pass; [1] * the software use config.{guess,sub} although not using autotools, thus econf cannot be used; [1] * the ebuild uses ./configure just for fun; [2] * the ebuild uses ../configure or variants thereof to run a different configure script than the one in the current directory; [3] * the ebuild uses an autogen script or some other autotools-rebuilding script that calls ./configure; [4] * the ebuild calls ./configure because it's doing an inline-build of another package. [1] Then see the procedure to handle this bug: [1] You cannot drop gnuconfig_update, so please leave the bug open, but set the status whiteboard to "Waiting autoepatch". [2] Fix the ebuild, use econf! [3] econf accepts a ECONF_SOURCE variable to tell it to run the configure found in another directory; to run ../configure just use ECONF_SOURCE=".." econf. [4] Fix your autotools with http://www.gentoo.org/proj/en/qa/autofailure.xml adnd then use econf. Once you're using econf, it will take care of updating gnuconfig by itself. Thanks from Diego and Mike
I wasn't even aware of it, but you're right. I'll be trying out to use aconf with the ECONF_SOURCE variable.
I've switched db-4.4 and db-4.5 (which are still both p.masked) to use econf and removed the gnuconfig_update lines. Everything *looks* okay, but I might have misunderstood something when I made the change.
(In reply to comment #2) > I've switched db-4.4 and db-4.5 (which are still both p.masked) to use econf > and removed the gnuconfig_update lines. > > Everything *looks* okay, but I might have misunderstood something when I made > the change. > Could we start pruning the versions that still use gnuconfig_update, or bump them to a new revision which doesn't use it? Thanks
absolutely. feel free to prune, change, or bump at will.
In 30 days, we can ask for stable and then remove the old gnuconfig-using versions: stable 3.2.9_p2, remove 3.2.9-r11 stable 4.2.52_p5, remove 4.2.52_p4-r2 stable 4.3.29_p1, remove 4.3.29-r2
After the stabilization is done on bug 237127, then we can remove the old ones.
due date has passed. i guess 3.2.9-r11, 4.2.52_p4-r2 and 4.3.29-r2 can be removed?! thanks
Fixed in CVS