(In reply to Richard Brown from comment #25) > After all, reviewing the comments here, all the substantive arguments > against _multibuild to date ONLY seem to apply to the devel projects. > The 'lacking controls' are controls which are not available in the OBS > Projects for Factory or our products anyway. > Therefore suggesting the devel project could still use source links as long > as the submitted kernel to our products used _multibuild seemed like a > diplomatic workaround to table. How would you imagine that to work, specifically? > The alternative would be to continue demanding that the long established > hard requirement for _multibuild be finally met, circular discussions would > likely continue, meanwhile ALP Product builds remain broken. Why are long established bugs in multibuild support not fixed if there is hard requirement for using multibuild? > The more esoteric arguments that _multibuild is fundamentally broken are > countered by the realities of our codebase > In Factory there are a grand total of 688 packages using _multibuild > (package list attached) > This list does not include the child-packages created as a result of > multibuild. ie. this is the de-duplicated number > This includes toolchain packages like cmake, gcc, glibc and is approximately > 4% of all packages in Factory I am not disputing that the Factory can be built with _multibuild. However, lack of support for multibuild in OBS degrades OBS usability in general. It also makes maintenance of develprojects and addon projects harder, requiring baroque workarounds. This increases load on package maintainers and detracts from OBS as a selling point of our distribution enabling easy contribution.