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