I have an ebuild for this. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 30355 [details] Ebuild for Expect Perl Module This ebuild has been tested and appears to function properly.
I see that a few bugs have been filed that are required by this, but what dependency does this module fill? In other words, does this bug meet the criteria listed here: http://www.gentoo.org/doc/en/policy.xml#doc_chap2 (see the perl section)
It fulfills the dependency that I need this package for software that I've written (self fulfilling dependency). I'm not sure what packages require the perl expect module, however I know that a lot of my code requires this. Think of this as a module as valuable as DateManip and as such should be added to the portage tree. As for which criteria it meets, I'm unsure, all I know is that this is the only module at cpan that provides this functionality. Could you inform me which it fills? Whoever wrote that criteria left it very cryptic. I have no idea what g-cpan is. Could you elaborate on that? What is a .PM vs the module? according to "The module(s) provide tools, applications or other features (i.e. more than what their .PM offers)" It would seem that the module and .PM are not the same thing.
To clarify, the policy is that we only add modules that either are a dependency of another package *in portage* or they provide additional tools. For example, LWP (libwww-perl) supplies, in addition to the modules, the lwp-mirror, GET, and POST command line utilities making it useful beyond just the modules. This is what is meant by "more than the .PM." As for g-cpan, it is a command line tool that automatically generates an ebuild for any perl module in CPAN and installs it properly. Try 'g-cpan.pl <some module>' for modules not in portage and do not meet the criteria. With regard to the criteria itself, it is very explicit in what will and will not be included in the portage tree. I do not see Expect as critical as DateManip or say DBI as unless it meets the criteria for some other reason, it will not be added. (On the other hand, if g-cpan does not work, feel free to reopen the bug and we'll add it.) Either way, thanks for hte submission.
I appreciate the clarifications greatly. I appologize for being a burden, I'll try to follow the rules closer from now on. Out of curiousity, why is dev-python/pexepect in the portage tree if dev-perl/Expect cannot exist? Same goes for dev-tcltk/expect. Obviously if those are included for their development environments, perl's Expect might be worth considering as valuable? g-cpan worked to install the module. I still think that Expect is a important enough tool that it should be included in the portage tree. But deem it as you will, I'm new to figuring out what qualifies as a valid ebuild. cheerio and again thank you for educating me
Python's pexpect is included because there are far fewer packages for the python team to maintain: esammer@ripley dev-python $ pwd /usr/portage/dev-python esammer@ripley dev-python $ ls -1 | wc -l 146 esammer@ripley dev-perl $ pwd /usr/portage/dev-perl esammer@ripley dev-perl $ ls -1 | wc -l 398 Python is not so stretched that it needs to limit what gets in. As for TCL's expect... esammer@ripley dev-tcltk $ ls -1 | wc -l 22 On top of that, TCL's expect package contains something like 7 command line tools including *the* expect binary that is used in shell scripting so it extends far beyond a TCL module.
