[gentoo-dev] static builds, static-libs useflag and indirect dependencies
Hi all, We used to install both shared and static libraries when both were available; this was good and working. Now we have the static-libs useflag to control when static libs are built and installed; this is better: we save time & space. The problem I want to raise here is about indirect dependencies with that new approach; let's take a real life example: We have xz-utils and libarchive with the static-libs useflag. I want to build freebsd-rescue statically against libarchive. What should I do? So far we depend on libarchive[static-libs] because we cannot guess the deps of libarchive. Thanks to pkg-config --static this is a non issue, unless xz-utils is built without static-libs and we enabled lzma support in libarchive! In this case, libarchive's static libs are useless if I don't have xz-utils' ones because the former requires the latter. For me, the current way of adding static-libs to packages only for controlling whether static libraries are installed is broken. I'd like to see the following as a guideline/rule for the static-libs useflag: 1) if a package has a static-libs useflag then its deps must be cat/pkg[static-libs?] when applicable. 2) if one wants to add a static-libs useflag to a package then one must check the reverse deps and make them happy with 1). Needless to say I am volunteering to scan & fix the tree to see this implemented quickly. Another option would be to make the package manager automagically handling the propagation of the static-libs useflag but that sounds more a hack than anything else. Alexis.
Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass
> "CM" == Ciaran McCreesh writes: CM> There's no need to offer the user the choice to do something that is CM> always broken. Your car doesn't have a "connect the exhaust fumes to CM> the air conditioning intake" button. Overriding portage's eclasses with one's own is not "always broken"; your analogy is not at all on point. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass
On Mon, Apr 19, 2010 at 04:58:57PM -0400, James Cloos wrote: > > "CM" == Ciaran McCreesh writes: > > CM> There's no need to offer the user the choice to do something that is > CM> always broken. Your car doesn't have a "connect the exhaust fumes to > CM> the air conditioning intake" button. > > Overriding portage's eclasses with one's own is not "always broken"; > your analogy is not at all on point. Overriding portage's eclasses with your own is already possible. You're asking to override portage's eclasses, without letting portage handle the fact that you are overriding eclasses. And that is a bad idea. You haven't commented, at least not in this thread that I have seen, on how to handle metadata changes as a result of eclass changes. Let's say this is in the tree: foo.eclass: DEPEND="dev-lang/python:2.6" bar-1.ebuild: inherit foo Let's say this is in your overlay: foo.eclass: DEPEND="|| ( dev-lang/python:3.1 dev-lang/python:2.6 )" Now you install bar. How should portage know that it must regenerate the metadata cache, to see that it doesn't need to install python 2.6 if you already have 3.1?
[gentoo-dev] Re: perl eclass review - EAPI=3 + new helper eclass
* Torsten Veller :
> The perl-module.eclass must be updated to support EAPI=3 [1] and
> a new eclass will be added which does contain some (more or less) useful
> stand-alone functions split from the old perl-module.eclass without
> exporting phase functions.
Somehow I was sleeping: It's more useful to set EXPORT_FUNCTIONS
conditionally and have all functions in perl-module.eclass.
I think this justifies the elimination of the perl-helper.eclass.
Sorry for the confusion. Hopefully wide awake now.
New perl-helper.eclass:
| # Copyright 1999-2010 Gentoo Foundation
| # Distributed under the terms of the GNU General Public License v2
| # $Header: $
|
| # @DEAD
|
| PERL_EXPORT_PHASE_FUNCTIONS=no
| inherit perl-module
Head of new perl-module.eclass:
http://git.overlays.gentoo.org/gitweb/?p=proj/perl-overlay.git;a=tree;f=eclass;hb=HEAD
| @@ -12,19 +12,19 @@
| # The perl-module eclass is designed to allow easier installation of perl
| # modules, and their incorporation into the Gentoo Linux system.
|
| -inherit perl-helper eutils base
| +inherit eutils base
| [[ ${CATEGORY} == "perl-core" ]] && inherit alternatives
|
| PERL_EXPF="src_unpack src_compile src_test src_install"
|
| case "${EAPI:-0}" in
| 0|1)
| - PERL_EXPF="${PERL_EXPF} pkg_setup pkg_preinst pkg_postinst
pkg_prerm pkg_postrm"
| + PERL_EXPF+=" pkg_setup pkg_preinst pkg_postinst pkg_prerm
pkg_postrm"
| ;;
| 2|3)
| - PERL_EXPF="${PERL_EXPF} src_prepare src_configure"
| + PERL_EXPF+=" src_prepare src_configure"
| [[ ${CATEGORY} == "perl-core" ]] && \
| - PERL_EXPF="${PERL_EXPF} pkg_postinst pkg_postrm"
| + PERL_EXPF+=" pkg_postinst pkg_postrm"
|
| case "${GENTOO_DEPEND_ON_PERL:-yes}" in
| yes)
| @@ -38,7 +38,17 @@ case "${EAPI:-0}" in
| ;;
| esac
|
| -EXPORT_FUNCTIONS ${PERL_EXPF}
| +case "${PERL_EXPORT_PHASE_FUNCTIONS:-yes}" in
| + yes)
| + EXPORT_FUNCTIONS ${PERL_EXPF}
| + ;;
| + no)
| + debug-print "PERL_EXPORT_PHASE_FUNCTIONS=no"
| + ;;
| + *)
| + DEPEND+=" PERL_EXPORT_PHASE_FUNCTIONS-UNSUPPORTED"
| + ;;
| +esac
|
| DESCRIPTION="Based on the $ECLASS eclass"
...
