We have seen several times in the past few months that one non-essential
package from feeds fails to build and stops the whole buildbot build.
Yesterday it was python-cffi, but it has been ola, ltq-vmmc etc.
It seems strange to me that non-essential packages from feeds, which by
definition are non-essential, can kill the whole buildbot build for a platform.
Normally a failing package gets marked "broken", but the build still
continues. However, some packages seem to kill the whole build when they fail.
As far as I have been able to determine, if the failing package contains
either a kernel module (kmod) or a "host section", then the failure of that
package is considered so essential that the whole builbot build run is
halted. The package is not just classified as "broken package", but the whole
build is really stopped.
I understand that a host section breakage from a tool, toolchain component or
a core package in the main Openwrt repo may be reason enough to halt the
build. Same goes for a kmod needed for the device to operate.
But when that failure happens to a package from e.g. telephony feed or a
python subpackage, I see no reason to stop the whole buildbot build run. The
more we have packages maintained in Github by a large group of people, the
more we will have this kind of accidental breakages by small non-essential
packages.
I propose that devs would change the buildbot build failure logic so that the
failing packages from the feeds would not kill the whole build. Failing
packages from feeds should just be marked as broken. That might require
splitting "package compilation" step to two different steps, one for packages
from the Openwrt main repo, one for packages from feeds. (or alternatively,
the essential packages should contain an ESSENTIAL definition on the
Makefile, or something like that, and the failure logic should take that into
account.)
This is a slightly reformatted version of my previous message about the same
subject in January 2015.
The topic is still important, so hopefully developers could think about it.
https://lists.openwrt.org/pipermail/openwrt-devel/2015-January/030719.html
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
