Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 21 Aug 2002 16:45:47 -0400
From:      Andy Sparrow <>
To:        Ken McGlothlen <>
Cc:        ports@FreeBSD.ORG
Subject:   RFC: Automated Port Rebuilding (was Re: using "dialog" in ports  is for bitches)
Message-ID:  <>
In-Reply-To: Message from Ken McGlothlen <>  of "19 Aug 2002 17:16:49 PDT." <> 

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
Content-Type: text/plain; charset=us-ascii

> Suddenly, I'm just not inclined to helpfully answer any of his questions
> anymore.

I can see why that might be.

Unfortunately, I personally heartily concur with the substance of the 
original mail, if not the manner in which it was expressed.

Other (including me) have expressed similar opinions recently, but they 
don't seem to have been taken into account. I think that the best 
statement of what I'm talking about, is that, following an 
upgrade/reinstall of world, at least some proportion of the userbase 
would like to automatically rebuild all the ports (with their original 
options) against the new world.

Portupgrade goes a long way to providing this, but the last pieces 
aren't there yet.

I think that the problem is adequately expressed:

*	People want to provide custom settings to certain ports, which they've 
found work well with their systems, configurations, preferences etc.

*	People don't necessarily want to sit there and be forced to interact 
with portupgrade in some hours time.

Custom Settings
It seems to me that we have a couple of mechanisms of providing 
arguments/options and other local settings to automated port builds, 
which is desirable for upgrading the entire machine, following an 
upgrade of world etc.

This would seem to be particularly useful when tracking -STABLE, or 
-CURRENT for that matter.

AFAIK, the two mechanisms (if there's more, please let me know) are as 

i)	Frobbing stuff into /usr/local/etc/pkgtools.conf

ii)	Frobbing stuff into ${PORT}/Makefile.local

I happen to prefer the latter approach, as I'd generally prefer that 
port options not be global, e.g. I might prefer to build some ports 
with, and some without, the same options.

Neither approach addresses the propensity of certain ports to bang up a 
dialog, and thus halt the entire portupgrade process until there is 
operator input. Sadly, in a typical scenario, said operator is busy 
having a life or sleeping at this point, having got the world 
rebuilt/reinstalled and just wants the ports rebuilt.

Yes, I'm aware of the BATCH=yes setting.

This, IMHO, doesn't entirely address the situation - because it merely 
ignores ports which are marked as "interactive".

In the case of the 'postfix' port (which changes quite frequently, 
thanks to whomever is working so diligently on keeping this up-to-date 
;-) for example, this "interactivity" consists of asking you which 
options you require.

It's the same for the Ghostscript port, and a similar situation exists 
with the various SNMP ports (which don't use dialog, but still prompt 
for their installation defaults). This is just off the top of my head - 
there must be dozens more ports that I don't use, but which cause their 
userbase the same pain.

Whilst this is acceptable for an initial install of the port, I think 
that it's not ideal for an automated port rebuild run - nor is it really 
acceptable to not rebuild all the ports, but ignore what might be the 
primary mail system (it is here) or an integral part of the printing 

What I'd personally like to see if dialog prompt an operator IF IT NEEDS 
TO. In other words, if appropriate settings are already provided via 
either pkgtools.conf or Makefile.local, then I think that dialog should 
not pop up, and the build should just proceed without human intervention.

Does anyone have any problems with the above suggestion? I really would 
like to see this (or anything that provides equivalent functionality) 
formalized, e.g. adopted and written up into the Porters Handbook.

I'm certainly prepared to provide patches (at least for those ports 
which bite me every two weeks or so) - but there's little point if 
no-one agrees that this is a good idea, particularly those with commit 

What we need is a constructive interchange and some concensus.



Content-Type: application/pgp-signature

Version: GnuPG v1.0.7 (FreeBSD)
Comment: Exmh version 2.5 07/13/2001



To Unsubscribe: send mail to
with "unsubscribe freebsd-ports" in the body of the message

Want to link to this message? Use this URL: <>