[Dev] [SCM] inter-package patch dependencies

Łukasz Stelmach l.stelmach at samsung.com
Mon Oct 21 10:23:41 GMT 2013


It was <2013-10-18 pią 17:30>, when Kanevskiy, Alexander wrote:
> On 10/18/13 18:12 , "Łukasz Stelmach" <l.stelmach at samsung.com> wrote:
>
>
>
>>It was <2013-10-18 pią 14:07>, when Kanevskiy, Alexander wrote:
>>> On 10/18/13 14:57 , "Łukasz Stelmach" <l.stelmach at samsung.com> wrote:
>>>>
>>>>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
>>>>dependencies.
>>>>
>>>>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.
>>>
>>> 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.
>>
>>This is simple, and obvious, and might help if the release numbers were
>>not generated by OBS. But because they are, and I think that it is
>>good. We need something more.
>>
>>I am refering to situations where merely a configuration option changes
>>or we introduce a patch to an upstream package, either way there is no
>>point in bumping the version.
>>
>>> 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.
>>
>>That is definitely useful and IMHO would help in some cases. However, it
>>will be quite cumbersome to use if depending changes are made to
>>packages from different domains and different people need to create the
>>same tag. If there was a way for the developer who posted the depending
>>changes (for both packages) to specify their dependency in the commit
>>messages we'd be cooking on gas.
>>

> Łukasz, can you provide some example where in such cases package A, B, C
> would be needed to submitted together and that would be not an API/ABI
> change ?

This depends on how broad is our definition of ABI. For example, it may
include list of image (png) files provided by a package built with
different options passed to the configure script.

> As for combined submit requests - the code works that people can
> "join" to the group request.  Meaning that maintainer of A can submit
> his package and provide "id" to maintainers of B and C.  Then
> maintainers of B and C can use same "id" to combine their changes into
> one group.  It doesn't need to be done in precisely in the same time.

But it depends on how fast the SR for A is accepted. If the SR for A is
accepted before maintainers of B and C push their tags. Then it won't
work. Am I right?

If the development model is going to be more open, then we may expect it
to be quite common that a single developer posts a few patches for
different packages (yes, topics, see below).

> As for cross repository dependencies:
> if we talking about just pure source code to coordinate between few people
> on reviews and merges - this can be achieved by using "topic"
> functionality in Gerrit.

Do you mean pushing with %topic= as described here[fn:1]. Looks
good. I can push patches to different repositories and mark them as
related. Is there any logic that prevents gerrit from generating SR in
OBS after pushing a submit-tag onto a single patch until all the patches
for a particular topic has been merged? Do maintainers need to push a
submit-tags for all changes in the topic.

> However, if we are talking about exposing on higher abstraction level
> dependencies between components -> those must be expressed as RPM
> dependencies. Otherwise we are re-inventing RPM.

I agree.

> And for build numbers, there are means where bumping "Release:" field
> in .spec file would lead to increased predictable number in resulted
> source/binary rpm in OBS.

Sounds promising. How can I post two patches to two different packages
(A and B) and describe their relationship. A won't work (Requires)
and/or build (BuildRequires) until B.rpm, rebuilt with the patch, is
available.

Footnotes:

[fn:1] https://review.tizen.org/gerrit/Documentation/user-upload.html#_git_push
-- 
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://lists.tizen.org/pipermail/dev/attachments/20131021/993693e5/attachment.sig>


More information about the Dev mailing list