Bug 81639 - fix devel/automake14's hardcoding versioned perl in ${LOCALBASE}/bin/automake14's shebang line
Summary: fix devel/automake14's hardcoding versioned perl in ${LOCALBASE}/bin/automake...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-05-29 23:10 UTC by Christopher Nehren
Modified: 2005-05-30 22:09 UTC (History)
0 users

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Nehren 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 Lucistnik freebsd_committer freebsd_triage 2005-05-30 22:09:03 UTC
State Changed
From-To: open->closed

Committed, thanks!