https://bugzilla.suse.com/show_bug.cgi?id=1219011 Bug ID: 1219011 Summary: cannot specify which multibuild package flavors to use for build in package metadata Classification: Internal Novell Products Product: openSUSE Build Service Version: master Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: backend Assignee: mls@suse.com Reporter: msuchanek@suse.com QA Contact: adrian.schroeter@suse.com CC: adrian.schroeter@suse.com, mls@suse.com Depends on: 1219005 Blocks: 1211226, 1218184 Target Milestone: --- Found By: --- Blocker: --- +++ This bug was initially created as a clone of Bug #1219005 +++ For some packages a number of different builds uses the same source. For consistency and efficiency it is required to upload the sources only once, and run multiple builds against the same sources. Historically this has been done by package links: The sources would be uploaded with a number of spec files, and a number of package links created. Because OBS selects the spec file to build based on container name the different package links would build different spec files. In other ways these package links appear as any other build containers. In particular, it's possible to select in what repositories (if any) the individual spec files should be used for build in the package container metadata. There is a push to convert these packages to use multibuild instead. With multibuild a _multibuild file is created that lists the spec files to build but only one package container is created in which all these spec files are built. That results in only one container metadata, and inability to specify which packages to use for build. https://github.com/openSUSE/open-build-service/issues/3574 This is important functionality for development of core packages. The kernel is used for building the kernel, binutils are used for building binutils, etc. When a broken version of such core package is uploaded into a develproject the develproject breaks, and will no longer produce any binaries. The answer is 'You can wipe binaries', and that's clearly the case. The kernel is uploaded using a custom script, and it does wipe the binaries as part of the upload. In this particular case it's also not particularly disruptive because the package that can break the build is also fast to rebuild. That is not the case with all packages. Wiping the binaries can be forgotten if done by hand, and then it will. Wiping the binaries always might be disruptive for some packages. The other option is to use some sort of bootstrap project setup. The release projects do use the various ring projects, and some toolchains bootstrap in quite elaborate ways because that's required for those particular packages. What these bootstrap setups have in common is that they are each one of a kind, very hard to understand for people who are not experts on OBS, and very fiddly. For some packages the 'use for build' flag was enough for setting up a project that can continuously build binaries as the developers upload changes, without breaking when a broken version is uploaded, without using special tools. Given that people working on toolchain or kernel are experts in that area and not necessarily on OBS project setup this feature is valuable for streamlining development of these core packages. Given that these core packages also typically use multiple spec files with one source file the 'use for build' is not longer available with multibuild, nor is any replacement. Clearly, having streamlined, standardized, and well-documented bootstrap project setup would also help, and solve the problem even for the cases where 'use for build' is not sufficient. -- You are receiving this mail because: You are on the CC list for the bug.