portupgrade bug: -M no longer works after v2.1.0

Atanas atanas at asd.aplus.net
Tue Jul 11 23:04:56 UTC 2006


Matthias Andree said the following on 7/11/06 1:48 PM:
> Atanas <atanas at asd.aplus.net> writes:
> 
>> Recent portupgrade versions no longer obey the -M command line switch,
>> i.e. any optional arguments to be prepended to each make command.
>>
>> How to reproduce:
>>
>> # portinstall -M "APACHE_HARD_SERVER_LIMIT=1024" www/apache13
>> ...
>> ===> src/ap
>> cc -c  -I../os/unix -I../include -I/usr/local/include  -funsigned-char
>> -O2 -fno-strict-aliasing -pipe
>> -DDOCUMENT_LOCATION=\"/usr/local/www/data\"
>> -DDEFAULT_PATH=\"/bin:/usr/bin:/usr/local/bin\" -DHARD_SERVER_LIMIT=512
>> `../apaci` ap_cpystrn.c
>> ...
>>
>> Note the -DHARD_SERVER_LIMIT=512 above.
> 
> Does it work if you type (you can omit the env in /bin/sh, bash, (pd)ksh
> and other Bourne-like shells):
> 
> env APACHE_HARD_SERVER_LIMIT=1024 portinstall www/apache13
> 
Of course it would, but this just bypasses the problem. There are other 
ways to work this around as well - like not using portupgrade at all and 
building everything with make.

The problem is that there's a bug introduced by some of the recent 
portupgrade versions that changes its documented behavior. The '-M' 
switch in partucular no longer works, thus causing any existing 
port/package installation scripts depending on that switch to build 
packages with incorrect optional parameters.

It's not a problem with a particular port. The www/apache13 port was 
given just as example how to reproduce the bug.

This affects _all_ ports when installed/upgraded/built via portupgrade 
and when the '-M' switch is used.

> (Isn't it time to migrate to a newer Apache version anyways? 8-) )
> 
(This is a long subject and kind of off-topic here. My short answer is 
no, or not yet. In some environments there are still legitimate reasons 
to use 1.3)

Regards,
Atanas


More information about the freebsd-stable mailing list