[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: databases/p5-gdbm "Review"
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:
> 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
>> 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
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
> 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
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:
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.
Main Index |
Thread Index |