Bug 81639
| Summary: | fix devel/automake14's hardcoding versioned perl in ${LOCALBASE}/bin/automake14's shebang line | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Christopher Nehren <apeiron> | ||||
| Component: | Individual Port(s) | Assignee: | freebsd-ports-bugs (Nobody) <ports-bugs> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | ||||||
| Priority: | Normal | ||||||
| Version: | Latest | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
State Changed From-To: open->closed Committed, thanks! |
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.