[Dev] orphan-packaging model

Markus Lehtonen markus.lehtonen at linux.intel.com
Thu Sep 4 09:52:48 GMT 2014


On 04/09/14 12:23, "Patrick Ohly" <patrick.ohly at intel.com> wrote:

>On Thu, 2014-09-04 at 03:12 +0000, Lv, RuiX wrote:
>> Hi Patrick,
>> The convert action only create the orphan packaging branch which only
>>contains packaging info.
>> Thus, you need to create the corresponding development branch that
>> contains libphonenumber source code with `gbs devel start`.
>> Please follow the following procedure, I've verified it on my side.
>> 1. Clone the package and switch to it.
>> $ git clone tizen: platform/upstream/libphonenumber
>> $ cd libphonenumber
>> $ git br
>> * accepted/tizen_common
>> 2. Convert to orphan-packaging model
>> 1) Create packaging branch.
>> $ gbs devel convert
>> $ git br 
>>   accepted/tizen_common
>> * accepted/tizen_common-orphan
>> 2) Create development branch
>> $ gbs devel start
>> $ git br
>>   accepted/tizen_common
>>   accepted/tizen_common-orphan
>> * development/accepted/tizen_common-orphan/5.3.2
>> 3. Do development on development branch and export patches to packaging
>> # Do local development.
>I did exactly that, and then I got stuck because of one key issue: how
>is one supposed to do local development now?
>"gbs build" fails:
>info: generate repositories ...
>info: build conf has been downloaded at:
>      /work/tizen/tmp/gbs/pohly-gbs/common.conf
>info: start building packages from: /tmp/libphonenumber (git)
>2014-09-04 06:06 +0000
>gbs 0.22.2
>error: No source package found at /tmp/libphonenumber
>error: <gbs>some packages failed to be built
>Patches are applied, but without "gbs build", one is limited to
>compiling on the host system, which is not the same as compiling for
>Tizen and not possible for many Tizen specific packages.

GBS build is supposed to work. What do you have in your ~/gbs.conf and
what command line are you using to build the package (plain "gbs build"
should be enough)?

>The development branch has no packaging directory. So even if "gbs
>build" worked on the development branch, I wouldn't be able to edit the
>packaging meta data. That only seems possible after checking out the
>packaging branch, at which point it is no longer possible to edit the
>source code. Right?

Yes. That is the point of the development model. Packaging (including
patches) resides on a separate branch. Source code is changed on the devel
branch and when you want to release the changes you need to "export" the
changes (i.e. commits -> patches) from devel to packaging branch.

>What seems doable is to check out the development branch, edit a file,
>export back to packaging branch, build *without committing*
>(--include-all), swap back to development branch, fix problem, rinse,
>repeat, ...
>However, even with a fast disk this implies constantly rewriting the
>file that I currently have open in my editor. At least emacs (and its
>users, including me) will not be happy about this ("the file has been
>updated - reload?" - if you accept, your undo history is lost).

Yes, that is suboptimal when doing fast edit-compile cycles. But as said,
gbs build from development branch should work. Just need to find out why
it doesn't work for you...

>The orphan-packaging model looks promising because it works without
>rebasing and thus allows reviewing upstream updates in Gerrit, but in
>practice it seems worse than the old model once patching the source is
>I think it would be more useful this way:
>- on the development branch, create the packaging directory with
>  a transient .gitignore for all of the packaging file such that
>  the packaging matches the current packaging on the packaging branch
>  minus the patches
>- use "gbs build" while on the development branch (needs some tweaking
>  to "gbs build" - I tried creating the directory manually, but gbs
>  wanted to work with the orphan branch instead)
>- during "gbs export" leave the potentially modified packaging
>  directory in place and just add patch information
>Bonus points if "git log/diff" works inside the packaging directory when
>on the development branch...

This could be done, of course, but I don't see too much advantage wrt the
current scenario (assuming building from devel branch works).

>Is it necessary to add the patches in the .spec file on the packaging
>branch? It would be better if that was left out of the .spec that that
>users edit/commit and only add this when exporting to OBS or building.
>The reason is that without adding/stripping the patches, the .spec file
>really is under full control of the user and never changes under his
>feet (see my comment about the editor above).
>Another nitpick: the "devel" subcommands are not symmetric. There's
>"start", but where is "stop"? The corresponding command is a combination
>of "export" and "drop". Once a development branch has been started, it
>is not obvious how one can continue to use it. A second "gbs devel
>start" complains and points to "git rebase", which is probably not the
>right solution. I suspect that "git checkout <development branch>" would
>be more appropriate.

Possibly the naming is confusing - gbs devel switch switches between the
pacakaging and devel branches.

>I think "export + drop" could be replaced by a single "stop" command
>which combines both operations, just like "start" does. Then it's
>symmetric: "start" = create branch and check it out <-> "stop" = switch
>back and delete branch.

Might be a good addition.

As a side note, the devel branches in Tizen could be permanent, too. I.e.
the devel branch(es) would be in Gerrit (not just local) and developers
would push their changes against that. Maintainer would then update the
packaging branch (through review, as weel) and eventually submit the

>> $ gbs devel export
>> $ git br
>>   accepted/tizen_common
>> * accepted/tizen_common-orphan
>>   development/accepted/tizen_common-orphan/5.3.2
>> 4. Commit patches and perform building.
>> $ git add * 
>> $ git commit -s 
>> $ gbs build -A i586
>Did this work for you? It fails here:
>$ schroot -c trusty-amd64 -- gbs build --profile common -A i586
>info: generate repositories ...
>info: build conf has been downloaded at:
>      /work/tizen/tmp/gbs/pohly-gbs/common.conf
>info: start building packages from: /tmp/libphonenumber (git)
>2014-09-04 06:33 +0000
>gbs 0.22.2
>info: prepare sources...
>info: start export source from: /tmp/libphonenumber ...
>info: Creating (native) source archive libphonenumber-5.3.2.tgz from
>info: package files have been exported to:
>     `
>[    2s] -----------------------------------------------------------------
>[    2s] ----- building libphonenumber.spec (user abuild)
>[    2s] -----------------------------------------------------------------
>[    2s] -----------------------------------------------------------------
>[    2s] + exec rpmbuild --define '_srcdefattr (-,root,root)'
>--nosignature --target=i686-tizen-linux --define '_build_create_debug 1'
>-ba /home/abuild/rpmbuild/SOURCES/libphonenumber.spec
>[    2s] Building target platforms: i686-tizen-linux
>[    2s] Building for target i686-tizen-linux
>[    2s] Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.PpF7ss
>[    2s] + echo 'Patch #0
>[    2s] Patch #0 
>[    2s] + /bin/cat
>[    2s] + /bin/patch -p1 --fuzz=2
>[    2s] can't find file to patch at input line 13
>[    2s] Perhaps you used the wrong -p or --strip option?
>[    2s] The text leading up to this was:
>[    2s] --------------------------
>[    2s] |From: Patrick Ohly <patrick.ohly at intel.com>
>[    2s] |Date: Tue, 9 Jul 2013 15:26:54 +0200
>[    2s] |Subject: fix compiler warnings about signed/unsigned int
>[    2s] |
>[    2s] |---
>[    2s] | 
>cpp/test/phonenumbers/geocoding/phonenumber_offline_geocoder_test.cc | 4
>The problem is that the generated libphonenumber-5.3.2.tgz only has the
>packaging meta data, but not the source.
>In a private reply Markus mentioned that it also failed for him and gave
>an explanation (something about gbs treating the package as
>"native" and how the branches are set up), but that went a bit over my
>head, so I am not sure how to fix it.
>So suppose you are still reading this ;-) and then new -orphan branch
>works. How do I push that back into the tizen repo? The -orphan branch
>needs to replace the "tizen" branch, right?

The above problem is caused by a missing upstream branch. GBS thinks the
package is "native" and thus doesn't create a correct upstream tarball
(but only makes a tarball out of the tip of packaging branch).

It seems that more sanity-checking logic in GBS would be good: all "devel"
commands should probably just fail if the package is native.


More information about the Dev mailing list