> -----Original Message----- > From: Kanevskiy, Alexander [mailto:[email protected]] > Sent: Friday, October 18, 2013 3:14 PM > To: Krzysztof Opasiak; Lukasz Stelmach; [email protected] > Subject: Re: [Dev] [SCM] inter-package patch dependencies > > On 10/18/13 15:21 , "Krzysztof Opasiak" <[email protected]> > 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.
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: [email protected] [mailto:dev- > >> [email protected]] On Behalf Of Kanevskiy, Alexander > >> Sent: Friday, October 18, 2013 2:07 PM > >> To: Lukasz Stelmach; [email protected] > >> Subject: Re: [Dev] [SCM] inter-package patch dependencies > >> > >> On 10/18/13 14:57 , "Łukasz Stelmach" <[email protected]> > >> 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 > >issue: > > > >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 > >[email protected] > > > > > > > > > > > > > > > -- > 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. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
