[Dev] [SCM] inter-package patch dependencies
alexander.kanevskiy at intel.com
Fri Oct 18 14:11:45 GMT 2013
On 10/18/13 16:32 , "Krzysztof Opasiak" <k.opasiak at samsung.com> wrote:
"Depends On"/"Needed By" in Gerrit and between patches are dependencies
within one component describing internal interfaces and dependencies of
We are talking here about breaking external dependencies between
Those in Tizen are declared on packaging level, using
If we end-up of putting dependencies on every single commit - we obviously
doing something really wrong in those low-level components.
Each component that is providing external interfaces, and directly or
indirectly affecting build or runtime functionality of other components
must provide some level of API/ABI stability for those interfaces.
Exposing issues via "unresolved" state would help us to identify lower
layer components that are constantly breaking external API/ABI.
Seeing that earlier would help to trigger some actions, like investigating
on how that change of external interfaces of component would affect SDK or
3rd party applications.
It also helps maintainer of low level components to understand, how much
breakages of interfaces affecting upper levels.
And I hope that eventually would lead to better architecture of those
components, as it is not something new on the Earth.
All big libraries and projects gone trough that path: glibc, glib,
libgnome*, qt*, you name it...
>> -----Original Message-----
>> From: Kanevskiy, Alexander [mailto:alexander.kanevskiy at intel.com]
>> Sent: Friday, October 18, 2013 3:14 PM
>> To: Krzysztof Opasiak; Lukasz Stelmach; dev at lists.tizen.org
>> Subject: Re: [Dev] [SCM] inter-package patch dependencies
>> On 10/18/13 15:21 , "Krzysztof Opasiak" <k.opasiak at samsung.com>
>> 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
>> version of B and C to properly be built.
>That's true but it's only an ugly hack. In this scenario we should
>specify a version number for almost each commit we have to depend on.
>Moreover this scenario won't fix this issue but only change the package
>status from failed to unresolveable.
>It would be great to have an opportunity to set those dependences before
>adding the submit tag. For example if someone is trying to merge changes
>in A they cannot be merged until changes in B and C will be merged.
>Similar mechanism exist in one project dependences. When you push a 2
>commit change, each commit has its own change-id so you have 2 reviews
>in Gerriy and the second change depend on the first one. You cannot
>merge the one commit which is on the top because you have to merge the
>previous commit first (see in gerrit fields Depends On, Needed By).
>> >> -----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
>> >> 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
>> >> to
>> >> release engineers that it require newer version of library.
>> >Here you are talking about library versioning. I think that
>> >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
>> >> 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
>> >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
>> >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
>> >package A is merged first and submitted in OBS but changes B and C
>> >still pending in Gerrit or has not been submitted already, what
>> >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
>> >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
>> the sole use of the intended recipient(s). Any review or
>> by others is strictly prohibited. If you are not the intended
>> recipient, please contact the sender and delete all copies.
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