| Summary: | Class::Accessor perl module | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Shaun Guth <l8nite> |
| Component: | New packages | Assignee: | Gentoo Perl team <perl> |
| Status: | RESOLVED INVALID | ||
| Severity: | enhancement | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | Class-Accessor-0.18.ebuild | ||
|
Description
Shaun Guth
2003-08-20 13:39:16 UTC
Created attachment 16384 [details]
Class-Accessor-0.18.ebuild
Attached ebuild - thanks :)
Shaun, Does this module add support for any existing or proposed ebuilds? Gentoo policy at this time is not to add perl modules unless they are a dependancy of another package - otherwise we recommend installing yourself from CPAN. I'll be uploading a new version of splat in the near future that can be modified to rely on this (if that's what it takes to get it accepted)... but there's nothing in portage that I know of currently that requires it.. Furthermore, in discussion with rac on #gentoo (and IRL at linuxworld), he mentioned that it was better policy to start letting portage handle all perl modules (as opposed to installing manually with CPAN). After a debate about the pros and cons, I've now moved my production systems to this method. I am writing ebuilds for those modules which I find I need, and this is one of them. Where are the policies located? Or who can I talk to about changing them? Here comes a statement of the policy, and you have the attention of the the two people you should talk to to affect it. At some point in the (hopefully not-to-distant) future, you will be able to type "emerge Perl::Module" (or Perl-Module, or something to that effect) and everything will work as you would hope, with no need for anybody to write or maintain ebuilds. Those ebuilds will almost certainly not live in dev-perl, because no automated system will work for 100% of the modules in CPAN. Some of them simply have weird build systems or dependencies on external libraries outside the Perl universe. We will need a safety valve, so actual ebuilds in dev-perl must take priority over those generated or simulated by any automated tool. At that point, we would like to minimize the number of ebuilds in dev-perl that would be adequately served by the automated portage <-> CPAN integration. If an ebuild is already in there, it will have to be either maintained or moved, neither of which is particularly appetizing. To this end, there is a stopgap tool called g-cpan.pl that is currently in the portage package. It is invoked by "g-cpan.pl Module::Name". If: (a) g-cpan.pl installs a particular module correctly (b) it depends on nothing outside of dev-perl (c) nothing outside of dev-perl depends on it ...we would like to avoid adding an ebuild for it. The final Portage <-> CPAN integration will handle correctly everything that g-cpan.pl handles correctly. If any of the above conditions is not met, we'll take the ebuild. Hope both the statement of policy and the rationale behind it is clear enough. > Hope both the statement of policy and the rationale behind it is clear enough.
Thanks for the detailed post rac! I am much more aggreable to the notion now that I know the motivation. Consider this bug closed - thanks :)
|
