Bug 205367 - Multiple ports: PERL should be used instead of PERL5
Summary: Multiple ports: PERL should be used instead of PERL5
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Ports Framework (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Port Management Team
URL:
Keywords: needs-qa, patch
Depends on:
Blocks:
 
Reported: 2015-12-16 22:05 UTC by Mikhail Teterin
Modified: 2015-12-17 20:09 UTC (History)
6 users (show)

See Also:


Attachments
Use ${PERL} instead of ${PERL5} (2.62 KB, patch)
2015-12-16 22:05 UTC, Mikhail Teterin
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mikhail Teterin freebsd_committer 2015-12-16 22:05:28 UTC
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.
Comment 1 VK freebsd_triage 2015-12-16 22:13:34 UTC
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.
Comment 2 Mikhail Teterin freebsd_committer 2015-12-16 22:25:55 UTC
(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.
Comment 3 Chris Hutchinson 2015-12-17 04:43:31 UTC
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
Comment 4 Mikhail Teterin freebsd_committer 2015-12-17 06:18:36 UTC
(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?
Comment 5 Kubilay Kocak freebsd_committer freebsd_triage 2015-12-17 06:33:20 UTC
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.
Comment 6 Kubilay Kocak freebsd_committer freebsd_triage 2015-12-17 06:36:08 UTC
Additionally, there is nothing precluding the creation of sub-issues under this 'parent' issue going forward, if the need arises.
Comment 7 Mikhail Teterin freebsd_committer 2015-12-17 06:42:37 UTC
(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...
Comment 8 Chris Hutchinson 2015-12-17 07:27:39 UTC
(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
Comment 9 Mikhail Teterin freebsd_committer 2015-12-17 07:41:26 UTC
(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...
Comment 10 Mathieu Arnold freebsd_committer 2015-12-17 13:20:40 UTC
Mmm, the patch is full of unneeded things, and I'm sure there are missing ones, I'll have a look.
Comment 11 Mathieu Arnold freebsd_committer 2015-12-17 13:25:24 UTC
(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.
Comment 12 Chris Hutchinson 2015-12-17 13:59:02 UTC
(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
Comment 13 Mikhail Teterin freebsd_committer 2015-12-17 14:13:24 UTC
(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.
Comment 14 commit-hook freebsd_committer 2015-12-17 17:20:13 UTC
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
Comment 15 Mikhail Teterin freebsd_committer 2015-12-17 17:26:27 UTC
(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?
Comment 16 Mathieu Arnold freebsd_committer 2015-12-17 17:31:47 UTC
(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 ?
Comment 17 Mikhail Teterin freebsd_committer 2015-12-17 17:34:36 UTC
(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.
Comment 18 Mathieu Arnold freebsd_committer 2015-12-17 19:20:41 UTC
(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.
Comment 19 Mikhail Teterin freebsd_committer 2015-12-17 20:09:48 UTC
(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.