ports/86642: portupgrade doesn't add MAKE_ARGS to install
David Gilbert
dgilbert at daveg.ca
Tue Sep 27 18:20:23 UTC 2005
>Number: 86642
>Category: ports
>Synopsis: portupgrade doesn't add MAKE_ARGS to install
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: freebsd-ports-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Tue Sep 27 18:20:21 GMT 2005
>Closed-Date:
>Last-Modified:
>Originator: David Gilbert
>Release: FreeBSD 6.0-BETA4 i386
>Organization:
DaveG.ca
>Environment:
System: FreeBSD canoe.dclg.ca 6.0-BETA4 FreeBSD 6.0-BETA4 #1: Wed Sep 7 13:42:49 EDT 2005 dgilbert at canoe.dclg.ca:/usr/obj/usr/src/sys/CANOE i386
This was a 5.4-RELEASE host that I found this on, but I don't
think it's version-specific.
portupgrade version was 'portupgrade-20041226_7'
>Description:
The port 'emulators/qemu' has an option 'WITH_KQEMU=YES' which
triggers the compilation of an additional kernel module to accelerate
the emulation.
However, it appears that 'WITH_KQEMU=YES' must be supplied to both the
'make' and the 'make install' command lines. I found this with
experimentation _not_ using portupgrade.
Since portupgrade always installs the version without KQEMU even though
the 'MAKE_ARGS' variable in /usr/local/etc/pkgtools.conf contains
'emulaltors/qemu' => 'WITH_KQEMU=YES',
... I conclude that portupgrade is supplying this to only the make
stage, where supplying it to both stages would produce more correct
behaviour.
>How-To-Repeat:
place the above line in /usr/local/etc/pkgtools.conf, and use
'portupgrade -f qemu'
to upgrade an existing qemu package.
>Fix:
supply 'MAKE_ARGS' variables to both 'make' and 'make install'
phases of portupgrade.
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-ports-bugs
mailing list