[Dev] [SCM] inter-package patch dependencies
k.opasiak at samsung.com
Fri Oct 18 13:32:47 GMT 2013
> -----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.
More information about the Dev