All imagemagick ebuilds that inherit perl-module seem to refuse to compile on systems that have a perl version < 5.8.2. This happens even with USE="-perl", which removes (as far as I can tell) any actual dependency on perl and perl-module. Are conditional inherits allowed? If so, the solution would look like (after the IUSE): if use perl ; then inherit perl-module fi Some discussion over here: #31544 Reproducible: Always Steps to Reproduce: 1. Remove perl or run a version prior to 5.8.2 (like OS X 10.3) 2. USE="-*" emerge imagemagick Actual Results: complains about the need for perl >= 5.8.2; refuses to install.
Sorry... should have been clearer: the block stems from the fact that even inheriting perl-module requires a perl version >= 5.8.2, regardless of whether or not you actually invoke any of the functions therein. More dicussion here: http://bugs.gentoo.org/show_bug.cgi?id=31544
Conditional inheritance is not allowed, since it breaks portage caching.
Really not seeing the problem here since we don't support <5.8.2 anyway, and even that support's on its way out.
Sorry -- the problem (reflected in the new summary) is that imagemagick always reports a dependency on perl, even when one isn't required. USE="-perl" emerge imagemagick shouldn't require perl at all, AFAIK, but because it inherits the perl module eclass unconditionally, it falsely reports a perl dependency. This is a bug that will hold true for any package that (a) provides an optional perl module through a "perl" use flag; (b) uses the perl module eclass; and (c) doesn't otherwise require perl. I don't know if any other such packages exist. The 5.8.1 vs. 5.8.2 stuff was just to indicate that the problem isn't just academic; there's at least one arch where the false dependency will prevent portage from attempting to build the package, even though the package compiles cleanly.
Still on a tangent that doesn't matter - imagemagick will need at least 5.8.2 to build its perl deps (not negating the validity of the claim about the use of eclass thereby needing perl, though perl is a gentoo system dep, ie to be a valid gentoo system, ported arch or not, you need perl). don't think i'm making any sense, let me try again...i see the validity of the report, and in another bug i am questioning the recent merging of perlmagick back into imagemagick all together since it seems to be broken in newer imagemagick installs, but on the flip, perl is a system requirement for gentoo afaik, regardless of whether you are a ported arch or a traditional linux install of gentoo. as such, i can tell you that the ported arch's need to be able to support the same minimal versions of perl that gentoo supports. on top of all of that - imagemagick in its latest incarnation (whether the ebuild reflects this or not) requires perl 5.8.2 to be able to support perl plugins.
Thanks for the repsonse. I think this bug report for imagemagick is still valid, though, because you can choose to compile imagemagick without perl plugins, but, if you do, portage still falsely claims that you need perl (v 5.8.2) installed on your system in order to compile imagemagick. The crux of this bug report is really that it's possible to compile imagemagick using the existing ebuilds on boxen without perl 5.8.2 as long as the -perl flag is used and the perl modules eclass is not inherited. The question about what is and isn't a valid Gentoo system is way beyond my level of competence... I think there's a broader conversation here about perl version support and gentoo on os x that the os x devs can choose to have or not have with the perl devs, given that Tiger is probably going to run 5.8.2 for its entire lifecycle. At a minimum, though, package dependencies should be accurate, which means that imagemagick's perl dep should be truly conditional. The solution may be to break apart imagemagick and perlmagick, but that's going to leave this problem in any other ebuilds that optionally build perl modules using the perl modules eclass.
bug in perl-module.eclass there's no way to inherit it optionally and/or say you want to use it based upon USE=perl
If this is a bug in the perl module eclass, does that mean that this bug should be reassigned to perl@gentoo.org? Should I file a new bug with them and mark this as a duplicate of that bug?
This bug looks like it's already assigned to the perl herd to me...
(In reply to comment #7) > bug in perl-module.eclass > How so? We won't support less than 5.8.2 (and are fast not supporting less than what's in the tree, which at present only goes as low as 5.8.6). And before you ask, yes, there are differences in the point release that make it difficult to support older perls.
i dont see how perl version is related in any way to this bug report you skipped the rest of my comment #7 which explains what the bug is
fixed in the eclass. Somewhat counterintuitive, but fresh coffee cleared the brain while going through outstanding bug reports.
