Date: Wed, 9 Nov 2016 15:40:02 +0100 From: Niklaas Baudet von Gersdorff <stdin@niklaas.eu> To: freebsd-questions@freebsd.org Subject: Re: After perl upgrade: "Can't locate XML/Parser.pm in @INC" Message-ID: <20161109144002.6uu3t6hbdcjafuav@box-hlm-03.niklaas.eu> In-Reply-To: <8d178a83-f0e1-687d-dd6c-ef50239287b7@FreeBSD.org> <d6285121d4c686db57e8fdf0ce43cca8@mhoenicka.de> <20161108175939.GB8641@lime.woodcruft.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20161109144002.6uu3t6hbdcjafuav>