Re: databases/p5-gdbm "Review"

[Jens Rehsack <rehsack%googlemail.com@localhost>]

2010/8/30 Greg Troxel <gdt%ir.bbn.com@localhost>:
>
> Jens Rehsack <rehsack%googlemail.com@localhost> writes:
>
>> 2010/8/29 Greg Troxel <gdt%ir.bbn.com@localhost>:
>>>
>>> What I don't understand is why pkg_rr should be special.  I think there
>>> are two classes of cases:
>>
>> It shouldn't - it should behave like any other batch build process.
>>
>>> 1) interactive questions are bad:
>>>
>>> pkg_comp
>>> pkg_rr
>> pbulk
>
> sorry, I thought pbulk ran inside pkg_comp but that's not the point and
> of course this belongs.
>
>>> package being built as a dependency
>>> normal user building a package
>>> pkg_developer building a package to see if it is ok
>>>
>>> 2) interactive questions wanted
>>>
>>> special mode for pkg_developer to make sure the non-interactive build
>>> is doing the right thing
>>>
>>> So I think it's a mistake to have BATCH_MODE, because it makes it appear
>>> that batch mode is special - but it's the normal case. Rather, we
>>> should have a PKG_ALLOW_INTERACTIVE mode.
>>
>> I fully agree. But I'd like to extend to a thought I have since I switched
>> from FreeBSD ports:
>> $ make config
>> This displays a dialog based config dialog where all tunables of the
>> package could be turned on/off (also supports radio buttons and
>> text fields). 'make depends-config' does 'make config' it for all
>> dependencies.
>>
>> In FreeBSD ports, BATCH_MODE turnes of PKG_ALLOW_INTERACTIVE.
>> When PKG_ALLOW_INTERACTIVE is true, "config" is in the build chain
>> between "fetch" and "extract".
>>
>> I liked the basic idea and would love to see a smiliar feature in pkgsrc
>> one day. But with your suggestion, it would be slightly more difficult.
>> But I'm sure you have a good answer for me.
>
> Probably the freebsd config feature is doing something quite different
> From what we were discussing.  What might make sense is an extension to
> have a config phase where the user gets to set *pkgsrc* variables, like
> PKG_OPTIONS.foo.  This is going to be disliked by many, by reasons (1)
> above, so it will have to default to off.

For sure - I don't want to create a second ports. But I rate it as a
nice feature
to set PKG_OPTIONS for packages where the users aren't firm.
I don't know which options I could set for GNome or XFCE (and all of
their dependencies), and I expect the greater amount of pkgsrc users
don't either.

> The other question is random questions not in the pkgsrc framework asked
> by the upstream bits.  My current, not super well considered, opinion is
> that this is always wrong and the solution is to add a PKG_OPTIONS
> option for each question to force it a particular way, and to have no
> remaining questions.
>
> If FreeBSD uses PKG_ALLOW_INTERACTIVE to mean 'enable freebsd config
> step', we should use a different variable.  Perhaps
> PKG_UPSTREAM_INTERACTION.

And now we're coming to my initial assumption: having some of those separately
enable/disable knowbs - but none of them should be on in BATCH_MODE.
So a common part in mk/somewhere.mk could look like:

.if defined(BATCH_MODE)
PKG_INTERACTIVE= no
PKG_UPSTREAM_INTERACTION= no
.else
PKG_INTERACTIVE?= no
PKG_UPSTREAM_INTERACTION?= no
.endif

Probably we wont want to override decisions the users do in mk.conf, but
PKG_DELEVOPER should have a similar behavior (when is "UPSTREAM
INTERACTION" wanted), but hasn't because it's to complicated.

/Jens