After perl upgrade: "Can't locate XML/Parser.pm in @INC"

[Niklaas Baudet von Gersdorff]

Frank Shute [2016-11-08 17:59 +0000] :

> With regards to mixing packages built with poudriere and those from the
> official repository; I think that's all very well if you accept the default
> options in poudriere. Once you start choosing your own options with poudriere
> you're going to end up in knots because you're likely to end up in dependency
> hell.
> 
> My advice: stick with either packages from the official repositories or from
> poudriere but not both.

Even if I configure the repositories with different priorities?

Of course, it makes sense to me that one repository is much less
complex and thus less vulnerable to (dependency) conflicts.
However, I decided for multiple repositories because I thought it
doesn't make sense for me to build a package with the same
options as built somewhere else. So I thought I could fetch the
ones that use the options I need from the official repository.

pkg.conf(5) even says:

  CONSERVATIVE_UPGRADE: boolean
   Ensure in multi repository mode that the priority is given as much as possible to the reposi-
   tory where a package was first installed from.  Default: YES.

To me this sounds like pkg is intended to be used with multiple
repositories.

> Personally, I now just stick with poudriere and configure the ports with my
> own options. Even though this machine (my strongest) isn't anything
> sensational: i5, 16GB, 80GB SSD, it still manages to build 542 ports/packages
> with plenty to spare and I can also distribute the packages to weaker hardware
> via http.

Yes, I also feed multiple machines from one central package
builder that isn't very strong either. But until now I've only
used the builder for some packages that I need.

Markus Hoenicka [2016-11-08 16:45 +0100] :

> your XML/Parser module is installed in .../mach/5.24/... but your Perl
> include path contains only the older versions .../5.20/... . So, Perl
> rightfully complains that it's not "there". You seem to have two Perl
> distributions installed in parallel, and some modules belong to the old,
> others to the newer Perl. Unless a manual cleanup (deinstalling 5.20 and
> associated modules) is successful, it might be prudent to deinstall all
> things Perl and reinstall the new version with all the modules you need.

Matthew Seaman [2016-11-08 15:49 +0000] :

> What version does ```perl -v``` return with?  If it's perl-5.20 then,
> correct, there is no XML::Parser available, as that has been installed
> in a perl-5.24 specific subdirectory of ${PERL5LIB}

That was the case indeed.

> If it's perl-5.24 that you want I suggest:
> 
>   # pkg delete -f perl5-5.20.3_15 perl5.24-5.24.1.r4
>   # pkg install perl5
> 
> Assuming you're using the latest pre-compiled packages (and not the ones
> from the quarterly branch which still have 5.20 as the default version.)
>  Or build and install a new perl-5.24 package.  It's important to
> re-install perl 5.24 as removing perl5-5.20 may have removed some
> important files from the existing 5.24 package.

This kind of solved the issue. At least I have a working perl
distribution again. Thank you!

What I don't understand though (maybe someone can help me with
that) is why pkg wants to downgrade perl to its previous version
if I issue `pkg upgrade`. See (extract):

  Installed packages to be DOWNGRADED:
    perl5: 5.24.1.r4 -> 5.20.3_13 [niklaas.eu-dev]

niklaas.eu-dev is the repository I use when porting. I only
update it (ports tree and packages) when I need it for testing.
It's priority is the lowest.

What could make pkg to decide to downgrade perl again?

    Niklaas