Hi, perl-modules.eclass seems like a decent eclass for perl modules. But we have some ebuilds (the one I know of is irssi) that can *optionally* create a perl module. Right now, it is using perl-modules.eclass, but this is a bad solution since perl-modules.eclass adds a perl runtime dependency that may not be needed for irssi. Suggested fix is the following: Create a perl-utils.eclass that provides the nice perl module helper functions. Any exported pre/post-inst functions in here should be conditional on "use perl" being set, ie.: pkg_postinst() { if use perl then echo foo fi } Update the perl-module.eclass to import perl-utils. Add DEPEND and RDEPEND to *this* eclass, so perl modules continue to get the automatic perl dependencies. I recommend moving the definition for MMSIXELEVEN *inside* of perl-module_src_prep and perl-module_src_install since it does not seem to be needed outside, and having extra calls to /usr/bin/perl is probably not a good idea from a dep-caching side of things. With these changes, perl modules can do: import perl-module And things like irssi can do: import perl-utils DEPEND="perl? ( sys-devel/perl )" RDEPEND="perl ( sys-devel/perl )" This way irssi can use the official perl module handling functions for its conditional perl modules.
Note: perl-module.eclass would override any existing functions that are conditional on USE=perl with ones that will always run.
The idea seems good but I think we need some naming schema foreclass. We have "elisp-common.eclass" that "elisp.eclass" inherits(we split these ebuilds just the same reason you are going to dofor perl). Also, we have "common-lisp-common.eclass" (who named it?)that "common-lisp.eclass" imports some functions from. Given theseeclass names I think "perl-common.eclass" would be better than "perl-utils.eclass" because you would think *-common.eclass is the eclassyou may use when you don't want all the DEPEND/RDEPEND.
I think this needs to wait until eclasses are rearchitected in portage-ng.
