tech-pkg archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Timeout on configure stage
On Wed, Nov 11, 2020 at 08:18:49PM +0000, Jonathan Perkin wrote:
> > > Op 11 nov. 2020, om 15:05 heeft Jonathan Perkin <jperkin%joyent.com@localhost> het volgende geschreven:
> > >
> > > 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.
> >
> > No disagreement here on your reasoning on the futility of marking
> > every failing package BROKEN. But I do think we agree that a package
> > hanging the bulk build should be addressed in some way and also
> > that listing them in a Joyent configuration file isn't quite general
> > enough.
>
> Yeh, like many things I patch and hack as I go to get things working,
> and then look to upstream things properly when I'm happy with them.
> This is just one of those things that is still on the TODO list, and
> they definitely shouldn't stay solely in my configuration files.
I didn't mean that everything that fails should be marked BROKEN; most
things that fail should just be fixed. Given that sometimes there is
no fix readily forthcoming, there are two cases where it's useful to
tag things: when they hang forever, and when they spend a long time
chugging away and then fail. In the former case, hitting one of these
requires manual intervention; in the latter, it doesn't, but it wastes
a lot of time to no useful result.
In both cases this is useful for everyone, not just bulk builders. It
doesn't follow that because I asked for package X, I know or care
about the existence of some 16x great-grand-dependency Y that is going
to turn out to hang my build.
NOT_FOR_BULK_BUILD is specifically useful for things that only go off
the rails in bulk builds, and yes, historically this does happen
enough to warrant having a lever for it.
(usually the trigger turns out to be something about build chroots)
> However that's still better than BROKEN*, which while logged in the
> report, do not count for the "Packages causing the most breakage", so
> can sometimes result in many packages being missing without notice.
The intended behavior is that BROKEN* leads to PKG_FAIL_REASON, which
should be reported as a failure, whereas the other NOT_FOR_* (e.g.
NOT_FOR_PLATFORM) lead to PKG_SKIP_REASON, which should not.
AFAIK pbulk still does not do this reporting correctly, and I think
the last time I asked Joerg about it he just said "no" without
explaining, but I could be confusing it with something else.
(note that from this point of view NOT_FOR_BULK_BUILD should really be
a BROKEN setting)
--
David A. Holland
dholland%netbsd.org@localhost
Home |
Main Index |
Thread Index |
Old Index