Mixing use of autotools-utils.eclass with regular phase functions and/or random econf/emake calls is unsupported and it never was. And in a near future, it will cause fatal errors during the build process. Please fix it by using correct autotools-utils phase functions as pointed out in the example on top of the eclass and/or its manpage. If you have any trouble, feel free to ping us and we'll help you fix it. Thanks.
I have an install failure due to this issue. The eqawarn function (called from remove_libtool_files) returns nonzero status (since I do not use QA logs), causing the whole src_install to fail. Maybe it is specific to paludis. Do you need more info?
The only thing we use is remove_libtool_files(). I really don't feel like using autotools-utils here, so it'd be nice if it were split out into eutils or something so we don't have to start duplicating code.
@base-system: Can we move remove_libtool_files from autotools-utils.eclass into eutils.eclass?
i'm not entirely convinced of its useful/correct-ness. i don't think there should be a "remove all" option, and generally i think package maintainers should be understanding the libraries they install and what is appropriate for removal. although you could say that even if people understand what's going on, they'd still want to use the func out of laziness ...
(In reply to comment #4) > i'm not entirely convinced of its useful/correct-ness. i don't think there > should be a "remove all" option, and generally i think package maintainers > should be understanding the libraries they install and what is appropriate for > removal. I agree; if we move it, there should be only one mode of operation. > although you could say that even if people understand what's going on, they'd > still want to use the func out of laziness ... It's still better than people do now. Because now, people usually copy random pieces of code like 'use static-libs ||' and randomly install useless .la files anyway.
(In reply to comment #4) > although you could say that even if people understand what's going on, they'd > still want to use the func out of laziness ... Or to avoid code duplication and not have to update every one of their ebuilds when policies change.
Well, I need to bump freetype and don't feel like inheriting an eclass that I have no control over that changes every week. So I'm just ripping any static lib logic out of the ebuild. Patches welcome. Fixed in 2.4.9. This version will be stable in a few days, and I'll drop the offending versions.
The change gives rise to bug 407663. How do we resolve the blocker?
