ports/81639: fix devel/automake14's hardcoding versioned perl in ${LOCALBASE}/bin/automake14's shebang line

Christopher Nehren apeiron at coitusmentis.info
Sun May 29 22:10:02 UTC 2005

>Number:         81639
>Category:       ports
>Synopsis:       fix devel/automake14's hardcoding versioned perl in ${LOCALBASE}/bin/automake14's shebang line
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-ports-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun May 29 22:10:01 GMT 2005
>Originator:     Christopher Nehren
>Release:        FreeBSD 5.4-RC1 i386
System: FreeBSD prophecy.dyndns.org 5.4-RC1 FreeBSD 5.4-RC1 #0: Sun Apr 3 17:04:59 EDT 2005 root at prophecy.dyndns.org:/usr/obj/usr/src/sys/PROPHECY i386

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.

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.
Index: Makefile
RCS file: /home/ncvs/ports/devel/automake14/Makefile,v
retrieving revision 1.54
diff -u -r1.54 Makefile
--- Makefile	17 Mar 2005 16:20:17 -0000	1.54
+++ Makefile	29 May 2005 21:58:53 -0000
@@ -24,7 +24,7 @@
 CONFIGURE_ARGS=	--program-suffix=${BUILD_VERSION}
 USE_PERL5=	yes

More information about the freebsd-ports-bugs mailing list