tech-pkg archive

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

Re: Timeout on configure stage



* 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.

-- 
Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com


Home | Main Index | Thread Index | Old Index