[New: openFATE 324890] Allow 'multibuild' to be disabled per project
Feature added by: Ludwig Nussel (lnussel) Feature #324890, revision 1 Title: Allow 'multibuild' to be disabled per project Buildservice: New Priority Requester: Mandatory Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: Following up on https://github.com/openSUSE/open-build-service/issues/3227 filed by Dominique Multibuilds are an interesting concept and I do like it a lot - but it causes a problem for the products using rings. I'll use a package of mine as a practical example (I did not convert it to multibuild yet, knowing of this problem. * libproxy - and libproxy-plugins libproxy lives in ring1 (basic library dependencies) and libproxy-plugins lives in ring2 (full KDE and GNOME extensions on top of libproxy, which uses a plugin model) now, with multibuild, I could not have libproxy builtin ring1 and libproxy:plugins in ring2 - they would only go together. My proposal would be a way to specify ring0/1/2 that multibuild is NOT to be considered (which would easily make for libproxy:plugins not to be built for ring1); but this then still lacks a good idea to ensure libproxy:plugins can be built in ring2 (preferably it would link to ring1/libproxy - we could then add some extra information into the _link to tell it what @BUILD_FLAVOR@ to use for this package -- openSUSE Feature: https://features.opensuse.org/324890
Feature changed by: Adrian Schröter (adrianSuSE) Feature #324890, revision 2 Title: Allow 'multibuild' to be disabled per project Buildservice: New + Milestone: 3.0 Priority Requester: Mandatory Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: Following up on https://github.com/openSUSE/open-build-service/issues/3227 filed by Dominique Multibuilds are an interesting concept and I do like it a lot - but it causes a problem for the products using rings. I'll use a package of mine as a practical example (I did not convert it to multibuild yet, knowing of this problem. * libproxy - and libproxy-plugins libproxy lives in ring1 (basic library dependencies) and libproxy- plugins lives in ring2 (full KDE and GNOME extensions on top of libproxy, which uses a plugin model) now, with multibuild, I could not have libproxy builtin ring1 and libproxy:plugins in ring2 - they would only go together. My proposal would be a way to specify ring0/1/2 that multibuild is NOT to be considered (which would easily make for libproxy:plugins not to be built for ring1); but this then still lacks a good idea to ensure libproxy:plugins can be built in ring2 (preferably it would link to ring1/libproxy - we could then add some extra information into the _link to tell it what @BUILD_FLAVOR@ to use for this package -- openSUSE Feature: https://features.opensuse.org/324890
participants (1)
-
fate_noreply@suse.de