Bug 81639 - fix devel/automake14's hardcoding versioned perl in ${LOCALBASE}/bin/automake14's shebang line
fix devel/automake14's hardcoding versioned perl in ${LOCALBASE}/bin/automake...
Status: Closed FIXED
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s)
Latest
Any Any
: Normal Affects Only Me
Assigned To: FreeBSD ports mailing list
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-29 23:10 UTC by apeiron
Modified: 2005-05-30 22:09 UTC (History)
0 users

See Also:


Attachments
file.diff (538 bytes, patch)
2005-05-29 23:10 UTC, apeiron
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description apeiron 2005-05-29 23:10:01 UTC
devel/automake14 specifies the CONFIGURE_ENV value PERL=${PERL5}. This causes
the installed bin/automake14's shebang line to point to that perl executable,
which is in fact versioned. If a user updates perl without also updating
automake14, their automake14 will be broken until they update (this can happen
in the course of a GNOME upgrade happening at the same time as a perl upgrade,
for example). This gives the confusing error message "command not found". By
changing the CONFIGURE_ENV to PERL=${PERL}, the versioned perl can be avoided
and automake14 will still work. The user will still need to do something to
properly update the dependency of automake14 upon the new perl, however.

How-To-Repeat: 1. Install some version x of perl.
2. Install devel/automake14.
3. Update the installed perl to some version y such that y > x.
4. Try to run automake14.
Comment 1 pav freebsd_committer 2005-05-30 22:09:03 UTC
State Changed
From-To: open->closed

Committed, thanks!