[Dev] [SCM] inter-package patch dependencies

Kanevskiy, Alexander alexander.kanevskiy at intel.com
Fri Oct 18 12:07:16 GMT 2013

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 >=
In such submits, if Application submitted first, it will be visible to
release engineers that it require newer version of library.

2. Synchronised submissions: in backend there is code (but not currently
actively used) that would group packages if they have exactly same submit
Those are considered as group and decision for them is taken atomically -
either all of them is accepted or all rejected.

>I saw this problem few times before and now a teammate of mine told me
>he's got it too. The problem I'd like to discuss is inter-package patch
>Sometimes we introduce some changes that need other packages to be
>changed too. So we change those too. Then, after the changes pass review
>and get merged they are submitted to OBS. But if they get submitted in
>the wrong order build-breaks occure.
>I wonder if we could develope some kind of dependency checking for
>submit requests. Commit messages could contain lines like "Requires:
>Iabcd*" refering to change-id (hash ids?) in different projects.
>Such solution might even reduce amount of work SCM need to do when they
>have to revert OBS commits to keep the packages OK.
>Łukasz Stelmach
>Samsung R&D Institute Poland
>Samsung Electronics

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