pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: databases/p5-gdbm "Review"

Jens Rehsack <> writes:

> 2010/8/27 Thomas Klausner <>:
>> On Thu, Aug 26, 2010 at 01:04:03PM +0200, Jens Rehsack wrote:
>>> 2010/8/26 Stoned Elipot <>:
>>> > Are you sure you want to add
>>> > PERL_MM_USE_DEFAULT=1 to lang/perl5/'s MAKE_ENV ?
>>> I'm pretty sure - otherwise each prompt() in Makefile.PL or Build.PL will 
>>> wait
>>> until a user answers. This is a no-go for pkg_rr or other, non-bulk-build
>>> updates.
>> Well, this should be caught by the package updater, shouldn't it? And
>> I don't remember that we had problems because of this before.
> I had several problems with that on some perl packages, especially
> while rebuilding all p5-* packages using pkg_rr. I run pkg_rr unattended
> (probably pkg_rr should define sth. like "BATCH_MODE", and
> PERL_MM_USE_DEFAULT should be set in BATCH_MODE only),
> and had 3 or 4 packages where the Makefile.PL/Build.PL waits for user
> input. So the pkg_rr runs the entire weekend instead of 18h.

I see your point, but I don't think this is really about pkg_rr.
Basically pkgsrc does not support the concept of interaction by a human
with the build system of something in a pkg.  pkg_comp and 'make
package-install' with dependencies both have the same problem as you are
running into, so doing something to pkg_rr isn't the right answer.

Another way to say that is that what you wonder about putting in
BATCH_MODE should just be the way it is.

It seems the problem is that perl needs to have separate switches to not
ask questions and to not load from CPAN.  What I think we want is for
any attempt to load from CPAN to simply result in immediate failure.
python has the same problem.

Attachment: pgpYrKiKdpilO.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index