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