On 3/12/26 11:22, bob prohaska wrote:
> On Thu, Mar 12, 2026 at 05:38:33PM +0100, Moin Rahman wrote:
>>
>>
>>> On Mar 12, 2026, at 17:37, bob prohaska <[email protected]> wrote:
>>>
>>> On Thu, Mar 12, 2026 at 05:06:16PM +0100, Moin Rahman wrote:
>>>>
>>>>
>>>>> On Mar 12, 2026, at 16:32, Kurt Jaeger <[email protected]> wrote:
>>>>>
>>>>> Hi!
>>>>>
>>>>>>>> I just noticed that a poudriere build of dns/bind920 is compiling
>>>>>>>> things like ghostscript and cups.... Is that necessary? Can it be
>>>>>>>> prevented?
>>>>>>>
>>>>>>> This might help, please test:
>>>>>>>
>>>>>>> make config
>>>>>>>
>>>>>>> DOCS=off
>>>>>>
>>>>>> Apologies for being obtuse, is this part of the poudriere command
>>>>>> or something done directly in /usr/ports?
>>>>>
>>>>> This probably can be done in /usr/ports/dns/bind920.
>>>>>
>>>>> I have not tested all the details, but if poudriere is set up properly,
>>>>> it should write some entries to:
>>>>>
>>>>> /var/db/ports/dns_bind920/options
>>>>>
>>>>> which can be copied to
>>>>>
>>>>> /usr/local/etc/poudriere.d/options/dns_bind920
>>>>>
>>>>> to be picked up in the next poudriere run.
>>>>>
>>>>>> As an aside, I'd like to
>>>>>> have the man pages, it's the GUI-related material that seems a waste
>>>>>> since this is for a headless server.
>>>>>
>>>>> I have not analysed this in full detail, but I'm not sure man pages
>>>>> and the rest can easily be seperatly build.
>>>>>
>>>>>> As an aside, quite a few Linux programs seem to have no man page.
>>>>>> It would be sad if FreeBSD went that route.
>>>>>
>>>>> I agree, but this depends on the port and the nitty-gritty details
>>>>> of the app itself.
>>>>>
>>>>> --
>>>>> [email protected] +49 171 3101372 Now what ?
>>>>>
>>>>
>>>> Easiest would be:
>>>>
>>>> % echo "dns_bind920_UNSET+=DOCS >> /usr/local/etc/poudriere.d/make.conf
>>>>
>>>
>>> Hmm, could one substitute
>>>
>>> echo "dns_UNSET+=DOCS" >> /usr/local/etc/poudriere.d/make.conf
>>>
>>> to make the setting apply to everything in /usr/ports/dns ?
>>>
>>> Thanks for writing!
>>>
>>> bob prohaska
>>
>> No. What you are looking for is:
>>
>> .if ${.CURDIR:M*/dns}
>> OPTIONS_UNSET+=DOCS
>> .endif
>>
>
> Something's wrong.
> I have
> # more /usr/local/etc/poudriere.d/make.conf
> .if ${.CURDIR:M*/dns}
> OPTIONS_UNSET+=DOCS
> .endif
>
> but
>
> # tail bind.log
> [00:16:53] [03] [00:00:00] Builder starting
> [00:16:53] [04] [00:00:00] Builder starting
> [00:20:49] [01] [00:03:57] Builder started
> [00:20:49] [04] [00:03:56] Builder started
> [00:20:49] [02] [00:03:56] Builder started
> [00:20:49] [03] [00:03:56] Builder started
> [00:20:49] [02] [00:00:00] Building graphics/poppler | poppler-25.10.0_1
> [00:20:49] [01] [00:00:00] Building print/harfbuzz-icu | harfbuzz-icu-12.3.2
> [00:20:49] [04] [00:00:00] Building print/texlive-texmf |
> texlive-texmf-20250308_1
> [00:20:49] [03] [00:00:00] Building x11-toolkits/pango | pango-1.56.4_1
>
> after restarting the poudriere bulk session.
>
> Need I go back and clean up in some fashion to extirpate existing
> DOCS-dependent packages?
>
> Actually, DOCS aren't what to suppress: The need is to suppress
> GUI-dependency, which imposes huge overhead and compatibility penalties.
>
> Might there be a no-GUI switch somewhere in poudriere?
>
> Interestingly, a second identical host running the same command:
> poudriere bulk -j main dns/bind920 dns/bind-tools > bind.log
> eventually built both ports but failed to complete all the
> GUI-related ports. That seems a bit odd.
>
> Thanks for writing,
>
> bob prohsk
>
>
My old memory (possibly/likely incorrect?) is that the Mk/bsd.options.mk
code:
# Some options are always enabled by default.
. for _opt in DOCS NLS EXAMPLES IPV6
. if ${COMPLETE_OPTIONS_LIST:M${_opt}}
PORT_OPTIONS+= ${_opt}
. endif
. endfor
lead to there being both the explicit OPTIONS_UNSET and an (implicit)
OPTIONS_SET for DOCS (when it is defined) and that the explicit
OPTIONS_UNSET did not necessarily work when both were present. My memory
is that it was something like OPTIONS_EXCLUDE that prevented the default
enabling by preventing the DOCS option from even being defined.
I also seem to remember running into examples of dependencies sometimes
also having DOCS defined of themselves, leading to tracing down more
than just the thing of direct interest in order for DOCS to not be
enabled to build the thing of direct interest.
In this context, dependencies need not also be under dns/ .
You might try:
.if ${.CURDIR:M*/dns}
OPTIONS_EXCLUDE+=DOCS
.endif
But, even if necessary, it might well prove not sufficient. It might not
be necessary. I just do not remember the full detail or how to find old
notes/materials related to when I ran into this area a few times in the
past.
Similar points go for the others: NLS EXAMPLES IPV6
An example might have been my trying to avoid DOCS or one or more of
those for devel/llvm* builds back when otherwise a lang/rust (?) build
ended up as a prerequisite for a while during a major update of some
area before everything got back to normal and rust ended up no longer
involved.
--
===
Mark Millard
marklmi at yahoo.com
