Created attachment 164300 [details] Use ${PERL} instead of ${PERL5} Some of the ports use ${PERL5}, where ${PERL} is sufficient -- and safer. The former can mean something like /usr/local/bin/perl5.22.1, whereas the latter is simply /usr/local/bin/perl. In particular, when PERL5 points to a NON-EXISTENT executable (as just happened on my system), the ports break. The proposed patch covers only the ports, where ${PERL5} is part of CONFIGURE_ARGS -- there are, likely, to be other ports affected by the same misunderstanding.
Thanks. I would advise you file one bug report for each of the ports since different maintainers would be involved and the workflow is more streamlined that way.
(In reply to Vladimir Krstulja from comment #1) > I would advise you file one bug report for each of the ports I wanted portmgr@ to, perhaps, revisit the very utility of the separate PERL5 knob -- and how it is set. Because the setting reflects not what IS, but what WOULD BE, if the relevant lang/perl5.XX was rebuilt anew. For example, I had the PERL5_DEFAULT set to 5.22 and the perl-5.22 installed. When the lang/perl5.22 got upgraded to 5.22.1 and I updated my ports-tree, PERL5 started pointing to the NON-EXISTING /usr/local/bin/perl5.22.1 instead of the perl5.22. These ports should not be using PERL5 to begin with, but if PERL5 is useful anywhere at all, it should be set correctly... I do not have a solution, so I'm just raising awareness. > since different maintainers would be involved and the workflow > is more streamlined that way Sorry, too much work.
This is an issue with the individual ports directly. Mk/Uses/perl5.mk works as intended. A pr(1) will need to be raised on the/any offending ports. --Chris
(In reply to Chris Hutchinson from comment #3) > Mk/Uses/perl5.mk works as intended Thank you very much, Chris, for the reassurance. But -- just so that no one has even a slightest shadow of doubt that, what seems like assuring confidence is, actually, mistaken arrogance -- could you, please, elaborate? For example, I described a scenario, where perl5.mk seems to offer an invalid path -- was that really intentional? If so, why is such behavior useful? Please, advise. Thanks, once again. > A pr(1) will need to be raised on the/any offending ports. Huh?! This stupefies me... What does a file-printing utility have to do with this problem?
This issue, given the fundamental nature of it, is a question of best-practice & compliance with regard to all perl ports, not just those mentioned in this issue. As such, this is one of the more appropriate candidates for a single issue (given the identical nature of change in individual ports) and the warrant to discuss and approve it at a framework (portmgr) level. In future, let's keep the personal and subjective tone/attitude off the issue tracker. Everyone is (rightly) trying to do awesome things.
Additionally, there is nothing precluding the creation of sub-issues under this 'parent' issue going forward, if the need arises.
(In reply to Kubilay Kocak from comment #5) > with regard to all perl ports, not just those mentioned in this issue I'm still unclear, what the purpose of the PERL5-setting is -- and whether the current implementation in perl5.mk actually serves that purpose. The comment inside the file states: # PERL5 - Set to full path of perl5, either in the system or # installed from a port. If the comment accurately documents the intention, then the implementation falls short -- it may set the variable incorrectly in a scenario I described. If the implementation is correct -- as Chris stated without elaborating -- then the comment needs to be corrected to avoid future confusion by maintainers of perl-using ports...
(In reply to Mikhail Teterin from comment #7) > (In reply to Kubilay Kocak from comment #5) > > with regard to all perl ports, not just those mentioned in this issue > > I'm still unclear, what the purpose of the PERL5-setting is -- and whether > the current implementation in perl5.mk actually serves that purpose. > > The comment inside the file states: > > # PERL5 - Set to full path of perl5, either in the system or > # installed from a port. > > If the comment accurately documents the intention, then the implementation > falls short -- it may set the variable incorrectly in a scenario I described. > > If the implementation is correct -- as Chris stated without elaborating -- > then the comment needs to be corrected to avoid future confusion by > maintainers of perl-using ports... Firstly; apologies, I misinterpreted your issue. This one reads *much* better -- for me, anyway. I haven't been able to duplicate what you've described happened to you, and while my development box tracks CURRENT, it is lagging about a month. Or because I still always use ${PERL5} ? Could an exp-run reveal this (the issue you describe)? I just checked out a copy of perl5.mk from HEAD. It's different enough from the one I'm currently using, that I going to take the time to perform a fresh install of CURRENT on one of the spares I have, and try and duplicate your described issue, tomorrow. I'll post back my findings either way. --Chris
(In reply to Chris Hutchinson from comment #8) > Could an exp-run reveal this (the issue you describe)? Most likely, no -- or else, it would've been revealed already. Exp-run performs a clean rebuild of everything. The problem with PERL5 being set incorrectly arises on a live system. Here is how: 1. Build and install perl -- by using a lang/perl5.XX port and set PERL5_DEFAULT to the 5.xx. In my case, the xx is 22, but it does not matter. 2. Wait for the port you chose to be upgraded -- in my case, it went from 5.22 to 5.22.1 3. Update your ports-tree. 4. Check the value of PERL5 -- by cd-ing into any perl5-using port and performing `make -V PERL5` The output of the above will point at the version of lang/perl5.xx, that WOULD BE INSTALLED, if you built the port today. Instead, it should point at the version, that IS INSTALLED on your system already. Now, maybe, the current behavior is, indeed, intended -- and only the comment needs fixing. But I can not imagine, why it is useful and so suspect, the implementation needs to be fixed instead: use pkg(8) to determine, whether A version of the desired lang/perl5.xx is already installed and, if there is one, use it. Hope, this helps...
Mmm, the patch is full of unneeded things, and I'm sure there are missing ones, I'll have a look.
(In reply to Mikhail Teterin from comment #9) > 1. Build and install perl -- by using a lang/perl5.XX port and set > PERL5_DEFAULT to the 5.xx. In my case, the xx is 22, but it does not matter. Let me start by saying that this is wrong. To set the default Perl, you put: DEFAULT_VERSIONS= perl5=5.xx You never set the _DEFAULTS variables by yourself.
(In reply to Mathieu Arnold from comment #11) > (In reply to Mikhail Teterin from comment #9) > > 1. Build and install perl -- by using a lang/perl5.XX port and set > > PERL5_DEFAULT to the 5.xx. In my case, the xx is 22, but it does not matter. > > Let me start by saying that this is wrong. > > To set the default Perl, you put: > > DEFAULT_VERSIONS= perl5=5.xx > > You never set the _DEFAULTS variables by yourself. _DEFAULTS is *hidden* isn't it? --Chris
(In reply to Mathieu Arnold from comment #11) > You never set the _DEFAULTS variables by yourself. These rules have changed so many times over the years, I may have lost track of the proper method du jour. But it does not matter -- that step is, actually, optional. I think, the "default default" is currently 5.20 -- so, you'll see the problem on any machine, which currently has perl-5.20.N installed, where N<3.
A commit references this bug: Author: mat Date: Thu Dec 17 17:19:50 UTC 2015 New revision: 403913 URL: https://svnweb.freebsd.org/changeset/ports/403913 Log: Fix usage of ${PERL5}. ${PERL5} points to a specific version of perl, say, perl5.22.1, it is fine to use it in a ports Makefile to do Perly things, but ports using it must use ${PERL}, that points to /usr/local/bin/perl so that if the minor version is updated, the shebang keep working. While there, make some ports use shebangfix, regen a few patches, and bump PORTREVISION where a shebang went from PERL5 to PERL. PR: 205367 With hat: portmgr Sponsored by: Absolight Changes: head/Mk/bsd.gecko.mk head/archivers/rpm2cpio/Makefile head/benchmarks/dbs/Makefile head/converters/nomyso/Makefile head/devel/p5-Sys-Virt/Makefile head/dns/ddclient/Makefile head/dns/ddclient/files/patch-ddclient head/german/BBBike/Makefile head/graphics/ImageMagick/Makefile head/graphics/ImageMagick7/Makefile head/graphics/cadubi/Makefile head/graphics/cbview/Makefile head/graphics/p5-ming/Makefile head/irc/pisg/Makefile head/irc/xchat-mircryption/Makefile head/mail/adcomplain/Makefile head/mail/adcomplain/files/patch-adcomplain.pl head/mail/assp/Makefile head/mail/bogofilter/Makefile head/mail/cyrus-imapd23/Makefile head/mail/cyrus-imapd24/Makefile head/mail/cyrus-imapd25/Makefile head/mail/cyrus2dovecot/Makefile head/mail/dkimproxy/Makefile head/mail/elmo-devel/Makefile head/mail/exipick/Makefile head/mail/imapsync/Makefile head/mail/mailagent/Makefile head/mail/pflogstats/Makefile head/mail/qmhandle/Makefile head/mail/rlytest/Makefile head/mail/sqlgrey/Makefile head/mail/swaks/Makefile head/math/abacus/Makefile head/math/p5-NetCDF/Makefile head/misc/biblical-curse/Makefile head/misc/kenny/Makefile head/misc/rfc/Makefile head/multimedia/ffmpeg/Makefile head/multimedia/ffmpeg0/Makefile head/net-im/jabberd/Makefile head/net-im/ttytter/Makefile head/net-mgmt/mrtg-ping-probe/Makefile head/net-mgmt/mrtg-ping-probe/files/patch-mrtg-ping-probe head/news/ubh/Makefile head/ports-mgmt/pkg_cutleaves/Makefile head/ports-mgmt/pkg_tree/Makefile head/ports-mgmt/portlint/Makefile head/print/cdlabelgen/Makefile head/security/amavisd-new/Makefile head/security/ipfcount/Makefile head/security/ipfwcount/Makefile head/security/nikto/Makefile head/security/oinkmaster/Makefile head/security/p5-App-Genpass/Makefile head/security/racoon2/Makefile head/security/regripper/Makefile head/security/smtpscan/Makefile head/security/sshblock/Makefile head/security/sshit/Makefile head/textproc/cdif/Makefile head/textproc/man2html/Makefile head/textproc/man2html/files/patch-man.cgi head/textproc/sarep/Makefile head/www/adzap/Makefile head/www/jspacker/Makefile head/www/p5-Net-eBay/Makefile head/www/p5-libapreq2/Makefile head/x11/xkbset/Makefile head/x11-fm/gprename/Makefile
(In reply to mat@ from comment #14) > Fix usage of ${PERL5}. Thank you, mat, for the prompt fix, but could you respond to my questions regarding the validity of the PERL5 setting? Or should that become a separate PR?
(In reply to Mikhail Teterin from comment #15) > (In reply to mat@ from comment #14) > > Fix usage of ${PERL5}. > > Thank you, mat, for the prompt fix, but could you respond to my questions > regarding the validity of the PERL5 setting? What part exactly ?
(In reply to Mathieu Arnold from comment #16) See comment #7. A system with perl already installed by port lang/perl5.XX will be setting PERL5 knob incorrectly, when the port is upgraded to install a different (micro)version.
(In reply to Mikhail Teterin from comment #17) > (In reply to Mathieu Arnold from comment #16) > See comment #7. A system with perl already installed by port lang/perl5.XX > will be setting PERL5 knob incorrectly, when the port is upgraded to install > a different (micro)version. Oh, you are talking about /usr/ports and /usr/local being out of sync, it is not supported. It works most of the time, but it is not supported. When you update your ports tree, you have to upgrade the ports that have been updated before being able to do anything else.
(In reply to Mikhail Teterin from comment #17) > Oh, you are talking about /usr/ports and /usr/local being out of sync, it is > not supported. It works most of the time, but it is not supported. Yes, I now recall you stating this opinion before. However, it was never substantiated -- neither by statements from other portmgr@ members, nor by references to public discussions arriving to this consensus. FreeBSD ports certainly tried to support such cases before -- if we really did depart from that view, I'd like to know, when it happened and whose decision it was. Please, advise... Thank you.