which is not needed with perl 5.8.6 as pod parsing scripts are included with it. eliminating need of PodParser would also resolve file conflicts between perl and PodParser
is there any update/work being done on this ?
what conflicts between perl and podparser? if this is because you have collision_protect in your features - can't help, that's a known problem and isn't forseeably overcomeable.
list of files from PodParser-1.28 which are already included in perl 5.8.6: pod2usage, podchecker, podselect, Checker.pm, Find.pm, InputObjects.pm, ParseUtils.pm, Parser.pm, PlainText.pm, Select.pm, Usage.pm (from lib/Pod directory) these are all fundamental files of PodParser
I wouldn't mark this as a conflict, per se. It is true, the ~x86 version of perl and the ~x86 of PodParser provide the same version. The ebuild for spamassassin is provided in large part from upstream, and I agree with the inclusion of this dep. This dep allows you to run the version of PodParser that they require *even if* you haven't upgraded your perl to 5.8.6. The whole point to having ebuilds like the PodParser ebuild is to provide the same level of module support no matter what version of perl you have installed locally. Not all users upgrade their perl frequently, and we have to support all of them, not just the ones who have.
and how about a modified ebuild which would check for perl version and, depending on that information, require PodParser ? i am asking because i have had major problems building other perl stuff when podparser was in place. removing it made everything work nice and smooth.
Unfortunately are conditional dependencies based on the version of an installed package (also the problem of bug 82920) not possible due to some portage restrictions (I think?). Wasn't there some tracker Perl bug about this...?
Why, yes, there is :) bug 84744, which is slow going. I'm opening bugs as I can, DB_File (which was mentioned in bug 81867) should be up to date (except for maybe mips). The delay is on my generating bugs, not the necessity for them.
Updating dependency.
This is adding trouble for Gentoo/FreeBSD (not for spamassassin but for gnome deps), as collision-protect is enabled to ensure that BSD userland don't get overwritten. News about this?
Sorry I must correct myself.. The problem, while being with gnome deps, is with spamassassin itself, thus removing cc on gnome (added comment about this on the tracker, tho).
Mass re-assign.
*** Bug 117042 has been marked as a duplicate of this bug. ***
for SpamAssassin? DEPEND=" || ( >=dev-perl/PodParser-1.22 >=dev-lang/perl-5.8.6 )...
(In reply to comment #14) > for SpamAssassin? > > DEPEND=" || ( >=dev-perl/PodParser-1.22 >=dev-lang/perl-5.8.6 )... > If you don't mind holding off on that thought...I'm working on a completely rewritten ebuild for dev-lang/perl, the next milestone of which is to remove those things we provide ebuilds for and pdepend them instead
Sounds good Michael
I caved and went with the || () syntax, which will work for the short term (adaptation issues with my ideas for a new perl ebuild have put that line on hold).
