Trying to install converters/p5-MIME-Base64 today, I get: ===> Registering installation for p5-MIME-Base64-3.14_1 pkg-static: lstat(/mi/ports/converters/p5-MIME-Base64/work/stage/opt/lib/perl5/site_perl/man/man3/MIME::Base64.3.gz): No such file or directory pkg-static: lstat(/mi/ports/converters/p5-MIME-Base64/work/stage/opt/lib/perl5/site_perl/man/man3/MIME::QuotedPrint.3.gz): No such file or directory pkg-static: lstat(/mi/ports/converters/p5-MIME-Base64/work/stage/opt/lib/perl5/site_perl/mach/5.10/MIME/Base64.pm): No such file or directory pkg-static: lstat(/mi/ports/converters/p5-MIME-Base64/work/stage/opt/lib/perl5/site_perl/mach/5.10/MIME/QuotedPrint.pm): No such file or directory pkg-static: lstat(/mi/ports/converters/p5-MIME-Base64/work/stage/opt/lib/perl5/site_perl/mach/5.10/auto/MIME/Base64/Base64.so): No such file or directory *** [fake-pkg] Error code 74 The files are present in ${STAGEDIR}, but not quite where expected. For example, PLIST_SUB sets PERL5_MAN3=lib/perl5/site_perl/man/man3, but the actual path is lib/perl5/5.10.1/man/man3. If PERL-5.10 is "too old" and not supported, the port's infrastructure should say so. Best would be for perl5.mk to deal with the old installs correctly...
For the record, my make.conf here (on FreeBSD-9/i386) says: # added by use.perl 2013-01-07 13:56:00 PERL_VERSION=5.10.1 so, 5.10.1 was still built on January of 2013, to be removed a month later, according to MOVED: lang/perl5.10||2013-02-04|Has expired: no longer under development, use lang/perl5.16 or lang/perl5.14 Seems like a rather tight schedule... Whatever the reasons for it, the handling of the older versions should've been retained in Uses/perl5.mk for much longer...
The supported versions in the ports tree are 5.16, 5.18 and 5.20. The default version is 5.18, and will be 5.20 in May. You should upgrade your system.
As a side note, I've been toying with the idea of having a package dependency and not a file dependency for USES=perl5, but it's a bit of a headache. I'm down to https://reviews.freebsd.org/D1442
(In reply to Mathieu Arnold from comment #2) > The supported versions in the ports tree are 5.16, 5.18 and 5.20. > The default version is 5.18, and will be 5.20 in May. > You should upgrade your system. I am sorry, but I reject the notion, that in order to be able to install a minor perl-module, I must upgrade my entire system first. Rebuilding perl5 would, for example, also require me to rebuild my KDE3 install -- for which there is no substitute in the ports-tree either (KDE4, infamously, is not such a thing). It is perfectly fine for FreeBSD to no longer provide the perl5.10 port, but it should still handle existing installs, where the old version is still present. Meanwhile, setting the following variables in make.conf helps me overcome the problem: SITE_PERL_REL= lib/perl5/site_perl/${PERL_VERSION} SITE_MAN3_REL= lib/perl5/${PERL_VERSION}/man/man3 SITE_ARCH_REL= ${SITE_PERL_REL}/${PERL_ARCH} The settings should, probably, be placed into Uses/perl5.mk -- conditional on the PERL_VERSION (or a related knob). But I am not sure, what exactly the conditions should be -- fixing things for 5.10-users, we should also check, where the 5.14 and 5.16 installed their bits... Another problem, that remains is the compression of man-pages -- the pkg-plist files of various p5-* ports list them with .gz suffixes, but the pages aren't actually compressed here... I added the following to my make.conf as a work-around: .if ${.CURDIR:T:Mp5-*} != "" post-install: -gzip -9 ${STAGEDIR}/${SITE_MAN3}/*.3 .endif but that's not a reliable solution. I am not sure, what to do about these -- I thought, pkg would handle (un)compressed man-pages automatically...
(In reply to Mikhail T. from comment #4) > I am sorry, but I reject the notion, that in order to be able to > install a minor perl-module, I must upgrade my entire system first. > Rebuilding perl5 would, for example, also require me to rebuild my KDE3 > install -- for which there is no substitute in the ports-tree either > (KDE4, infamously, is not such a thing). We do not support partial upgrades, never had, never will. If you need to do something Perl related with a non supported, outdated, expired version, upgrade your ports tree to before r373448. Anything at or after that commit, you *will* need a Perl version >= 5.14.4_8, 5.16.3_12, 5.18.4_5, 5.20.1_4. Though, skipping up to 5.14.4_14, 5.16.3_18, 5.18.4_11, 5.20.1_10 would be a way better idea.
(In reply to Mathieu Arnold from comment #5) > We do not support partial upgrades, never had, never will. Mathieu, what "partial upgrade" are you talking about? I just want to add a new perl-module to my existing install. Is that an invalid use-case in your opinion? > If you need to do something Perl related with a non supported, > outdated, expired version I really don't care, which perl-version I have installed -- and would've upgraded it, had it been possible. But it is not -- because you "do not support partial upgrades", so I'm sticking with 5.10.1. The module I'm trying to add does not insist on a newer version of Perl, so why can't I install it? Because perl@ folks are too cool to give any thought to Perl installed 2 years ago?
(In reply to Mikhail T. from comment #6) > Mathieu, what "partial upgrade" are you talking about? I just > want to add a new perl-module to my existing install. Is that > an invalid use-case in your opinion? I mean that the ports tree you are using to install the module you are talking about is *not* the one you have installed Perl 5.10 from. When you upgrade your ports tree without upgrading all the installed ports first, there is absolutely no guaranty, at all, that installing anything will work.
Created attachment 151364 [details] Set paths depending on installed perl's version This patch fixes the problem for me. It sets the various paths differently for different Perl-versions (might need adjustment for Perl-1.14). Also, the MANDIRS settings was independent from the SITE_MAN-setting -- this caused my confused with man-pages described in Comment #4. The patch also corrects handling of P5MANx, but I could find no ports which declare such a knob -- perhaps, it should be removed for good.
(In reply to Mathieu Arnold from comment #7) > I mean that the ports tree you are using to install the module you are talking > about is *not* the one you have installed Perl 5.10 from. > When you upgrade your ports tree without upgrading all the installed ports > first, there is absolutely no guaranty, at all, that installing anything will > work. There is never such a "guarantee" at all -- even when ports tree is the same. More generally, I've encountered enough problem with software (both free and otherwise) over the years to talk seriously about any "guarantee". All we are talking about is "reasonable effort" -- if you want legalese. My patch provides fixes the reported problem with very little effort -- please, consider committing it, or allowing me to.
(In reply to Mathieu Arnold closing the report) Mathieu, please, state for the record, why do you consider yourself in a position to close this PR. Are you doing it as a member of perl@, or portmgr@ or with some other hat on? Thank you.
As the maintainer of Perl.