[Dev] [SCM] inter-package patch dependencies

Kanevskiy, Alexander alexander.kanevskiy at intel.com
Fri Oct 18 13:13:51 GMT 2013

On 10/18/13 15:21 , "Krzysztof Opasiak" <k.opasiak at samsung.com> wrote:

The scenario you're describing where package A will be not buildable until
package B and C not submitted means that packages B and C are directly or
indirectly used as build dependencies for package A.
So, scenario 1, as I wrote earlier, with specifying in package A

BuildRequire: B >= $version_of_B_with_fixes
BuildRequire: C >= $version_of_c_with_fixes

would do the trick. it will explicitly specify that package A needs some
version of B and C to properly be built.

>> -----Original Message-----
>> From: dev-bounces at lists.tizen.org [mailto:dev-
>> bounces at lists.tizen.org] On Behalf Of Kanevskiy, Alexander
>> Sent: Friday, October 18, 2013 2:07 PM
>> To: Lukasz Stelmach; dev at lists.tizen.org
>> Subject: Re: [Dev] [SCM] inter-package patch dependencies
>> On 10/18/13 14:57 , "Łukasz Stelmach" <l.stelmach at samsung.com>
>> wrote:
>> There are few things here:
>> 1. API changes that are not explicitly declared.
>> Normally it's handled that e.g. Library XYZ starts to provide new
>> API that
>> supposed to be used by application.
>> API is provided in version V1. Then, best practice is, if
>> application
>> require that API to declare build dependency: BuildRequire:
>> Library-XYZ >=
>> V1
>> In such submits, if Application submitted first, it will be visible
>> to
>> release engineers that it require newer version of library.
>Here you are talking about library versioning. I think that definitely
>it would be necessary to have such mechanism on our platform and to have
>repositories for this. This would allow other packages to request for a
>certain version of library not only the newer one as is now.
>> 2. Synchronised submissions: in backend there is code (but not
>> currently
>> actively used) that would group packages if they have exactly same
>> submit
>> tag.
>> Those are considered as group and decision for them is taken
>> atomically -
>> either all of them is accepted or all rejected.
>Maybe this mechanism could be used. Please let me highlight current
>We are trying to fix up build breaks on our platform. To do this we need
>to fix up package A which is unable to build. While investigation we
>found out that to fix this package we have to update packages B and C.
>We create all three patches and submit it in Gerrit. The change for
>package A is merged first and submitted in OBS but changes B and C are
>still pending in Gerrit or has not been submitted already, what means
>that package A won't build in GBS.
>There should be some mechanism that allow me as a committer to show that
>changes B and C has to be merged and submitted before changes in A.
>Krzysztof Opasiak
>Samsung R&D Institute Poland
>Samsung Electronics
>k.opasiak at samsung.com

Best regards, Alexander Kanevskiy.

Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

More information about the Dev mailing list