Re: Timeout on configure stage

[Thomas Klausner <wiz%NetBSD.org@localhost>]

On Wed, Nov 11, 2020 at 02:05:55PM +0000, Jonathan Perkin wrote:
> * On 2020-11-11 at 13:29 GMT, Greg Troxel wrote:
> 
> > David Holland <dholland-pkgtech%netbsd.org@localhost> writes:
> > 
> > > On Sun, Nov 08, 2020 at 09:48:18PM +0000, Jonathan Perkin wrote:
> > >  > > I'll go through all of them and verify. I've already added
> > >  > > BROKEN_ON_PLATFORM to ja-groff since the problem isn't specific to
> > >  > > bulk builds. Is this ok, and can I add them to the others too after
> > >  > > verification?
> > >  > 
> > >  > I tend to prefer NOT_FOR_BULK_PLATFORM for bulk build hangs, as it
> > >  > doesn't affect trying to build the package manually, e.g. when trying
> > >  > to fix it, but yeh adding them would be good with a comment to explain
> > >  > where it's hanging.
> > >
> > > It's easy enough to comment out BROKEN annotations when testing or
> > > debugging.
> > >
> > > I would encourage marking things known to be broken because this also
> > > protects people running pkg_rr and other tools, as well as the case
> > > where you start something building, go off to make dinner, and come
> > > back to find that it's hung.
> > 
> > Agreed.
> > 
> > How many cases do we have when the build works fine with "make package"
> > or under pkg_rr, but fails in bulk?
> 
> It has nothing to do with that.  The point is that a bulk build will
> attempt to build everything, whereas a pkg_rr or make package is very
> different, you have specifically told it what subset of pkgsrc you
> want to build.
> 
> A person running a bulk build does not want to have to manually
> intervene every single time to kill stuck processes, they're only
> interested in a complete report, so we have NOT_FOR_BULK_PLATFORM to
> skip those packages in that environment.
> 
> A user who has specifically requested a package however will, by
> definition, want that package.  Adding BROKEN is fine in the situation
> where the package clearly cannot build on the target system due to
> some restriction or missing functionality, but I don't like it being
> used when it might be a trivial fix, and one where the user who
> experiences the hang will be perfectly placed to have a quick look to
> see what's causing it.  After all, it is in their interest to see what
> the problem is, as it is software they are specifically trying to
> install!
> 
> We've been around this argument before however, so if people still
> disagree with me I suggest you just go ahead and remove
> NOT_FOR_BULK_PLATFORM entirely, as if you're just going to use the
> BROKEN sledgehammer for everything then it seems entirely pointless,
> and we can avoid future arguments.

I think it's not a disagreement on the argument, but that just that
not everyone remembers every argument ever on the mailing lists :)

Please document NOT_FOR_BULK_PLATFORM and the reasoning and we should
be fine.

# cd /usr/pkgsrc/doc
# grep -r NOT_FOR_BULK_PLATFORM .
#

 Thomas