| Summary: | g-cpan fails to recognize dependencies | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Rusty Phillips <rustyp> |
| Component: | [OLD] Development | Assignee: | Gentoo Perl team <perl> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | kiyoshi.aman |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | g-cpan | ||
| Package list: | Runtime testing required: | --- | |
|
Description
Rusty Phillips
2005-07-19 12:46:53 UTC
(In reply to comment #0) > g-cpan will not recognize most perl module dependencies in it's download > process, so two similar builds will result in the same modules getting installed > twice. Actually, the problem is in how the list is passed to portage, not in what g-cpan is recognizing as a dep (not arguing, just clarifying the point a bit). > > Further, it doesn't create ebuilds for any of the dependencies. OK, for this I need examples, because everything generated with g-cpan 0.13.02 over here either points to an existing ebuild or points to perl-gcpan/ generated ebuilds. > Reproducible: Always > Steps to Reproduce: > 1. Install two similar modules that both have a lot of dependencies using > g-cpan- for example, CGI::Session and CGI::Session::DB2 or CGI::Builder::TT2 and > CGI::Builder * Well..CGI-Session is in portage, so good luck on creating something for that with g-cpan ;) * CGI::Session::DB2 generated, but has missing deps - due to the way g-cpan *currently* checks for dependancies, ie via the cpan shell, this is doomed to fail forever because the author doesn't package a Makefile.PL. * Ebuilds were generated for both CGI::Builder and CGI::Builder::TT2. Deps aren't right, again, this is a bug in the interaction with cpan (hint: I welcome patches to g-cpan for a cleaner, non-cpan based way to check deps...) So I'm bumping this down to normal - this isn't severe, it isn't blocking your box from continuing to function or stopping you from booting. g-cpan is currently only as good as the cpan<->Makefile.PL interaction of the package in question. Well, along those lines you might try using Module::Depends or Modules::Depends::Intrusive to figure out dependencies rather than CPAN. Those are a supposedly a little better at figuring it out. If I have time I might send you stuff...but I wouldn't count on it. Too many other little projects already. Beyond that, perhaps g-cpan could watch the output of the build process to see if something gets installed and *then* add to the dependency list? More examples: the primary examples I was working with were from CGI::Builder. CGI::Builder CGI::Builder::Session CGI::Builder::TT2 CGI::Builder::Auth Beyond these, try AnyData DBD::AnyData I can let you know of more when they come up, but hopefully that'll be enough for you to work with. (In reply to comment #2) > Well, along those lines you might try using Module::Depends or > Modules::Depends::Intrusive to figure out dependencies rather than CPAN. I'd looked into the Modules::Depends - but the list of supporting deps is staggering (right now g-cpan has no external deps). I'll klunk something out of it :) Those > are a supposedly a little better at figuring it out. If I have time I might > send you stuff...but I wouldn't count on it. Too many other little projects > already. heh - story of my life these days. I appreciate you understanding where I'm at with this. I'm transferring this bug over to my personal account (vs. perl@g.o) since I'm primary maintainer and current author at large for g-cpan (at least for committing to cvs/svn) Since most people are going to be transitioning from cpan to g-cpan, the biggest problem will be incorrect passing to portage, not cpan dependency problems. So that's the thing to fix here. Mass re-assign. This may be related. If not, I can open a new bug. When g-cpan runs into a dependency for which a ebuild already exists, but is masked, it complains and stops. If I emerge that package with ACCEPT_KEYWORDS='~x86', it gets installed. However, when I re-run g-cpan on the original CPAN module that I was trying to install, it stops dead on the dep again. Here is an example: sudo g-cpan -i Net::Amazon [...] * g-cpan: Existing ebuild found for perl-core/Time-HiRes * g-cpan: Existing ebuild found for dev-perl/Log-Log4perl * g-cpan: perl-gcpan/Net-Amazon created in /tmp/perl-modules_12068 Calculating dependencies \ !!! All ebuilds that could satisfy "dev-perl/Log-Log4perl" have been masked. !!! One of the following masked packages is required to complete your request: - dev-perl/Log-Log4perl-0.50 (masked by: ~x86 keyword) For more information, see MASKED PACKAGES section in the emerge man page or section 2.2 "Software Availability" in the Gentoo Handbook. : jmglov@laurana; ACCEPT_KEYWORDS='~x86' sudo emerge \dev-perl/Log-Log4perl [...] >>> Regenerating /etc/ld.so.cache... >>> dev-perl/Log-Log4perl-0.50 merged. >>> Recording dev-perl/Log-Log4perl in "world" favorites file... >>> clean: No packages selected for removal. >>> Auto-cleaning packages ... >>> No outdated packages were found on your system. * GNU info directory index is up-to-date. : jmglov@laurana; sudo g-cpan -i Net::Amazon [...] * g-cpan: Existing ebuild found for perl-core/Time-HiRes * g-cpan: Existing ebuild found for dev-perl/Log-Log4perl * g-cpan: perl-gcpan/Net-Amazon created in /tmp/perl-modules_12068 Calculating dependencies \ !!! All ebuilds that could satisfy "dev-perl/Log-Log4perl" have been masked. !!! One of the following masked packages is required to complete your request: - dev-perl/Log-Log4perl-0.50 (masked by: ~x86 keyword) For more information, see MASKED PACKAGES section in the emerge man page or section 2.2 "Software Availability" in the Gentoo Handbook. Re-assign. As near as I can tell, this is all fixed in 0.14.0_rc2, can you confirm? (In reply to comment #8) > As near as I can tell, this is all fixed in 0.14.0_rc2, can you confirm? > The problem in #6 is still an issue in 0.14.0. It appears that g-cpan is not honoring the version requirements of the module itself, but instead if there is a portage package, it is making the highest version currently in the portage tree, irrespective of mask status, the minimum dependency. The example I ran into was Date::Simple, which requires Test::Simple with no version specified. In portage, virtual/perl-Test-Simple is marked stable to 0.62 and masked ~x86 for 0.63 and 0.64. The DEPEND in the ebuild was >=virtual/perl-Test-Simple-0.64. Since I'm not running ALLOW_KEYWORDS="~x86" on this box, the install failed with all ebuilds masked as did Josh's when it would have been perfectly acceptable to proceed with 0.62. Ideally I would expect g-cpan to require the same version as the cpan package requires. If the cpan package does not specify a version requirement, as in this case, the ebuild should not either. Second best in my opinion would be not to make the ebuild depend on any particular version assuming that any in portage are reasonably recent and so good enough. That would allow the user's setup to determine whether to pull the latest stable version in portage or latest and greatest as appropriate for them. The second option could be accomplished by removing the if on 630 of g-cpan.pl and always executing the else. Sorry, I don't know CPAN well enough to suggest how to implement the first. Related to the last comment is that g-cpan [0.14.0, for reference] is generating bad versions. e.g., g-cpan -i Config::XPath generates an ebuild that depends on Error-0.17008; there is no 0.17008 [there's a 0.17.008], so you can't emerge Config-XPath unless you fix the dependency by hand. (In reply to comment #9) > It appears that g-cpan is not honoring the version requirements of the module > itself, but instead if there is a portage package, it is making the highest > version currently in the portage tree, irrespective of mask status, the minimum > dependency. fixed in svn http://sources.gentoo.org/viewcvs.py/gentoo-perl/g-cpan/trunk/ 0.15_rc1 is in the tree and contains fixes that cover this bug. |
