[Dev] orphan-packaging model

Patrick Ohly patrick.ohly at intel.com
Thu Sep 4 09:23:03 GMT 2014


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 branch.
> # 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.

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?

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).

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
necessary.

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...

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.

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.


> $ 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 --include-all
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 '2206e257dd44f1e1d4640bb906ed98bbe2f69ef3'
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 (0001-fix-compiler-warnings-about-signed-unsigned-int-cons.patch):'
[    2s] Patch #0 (0001-fix-compiler-warnings-about-signed-unsigned-int-cons.patch):
[    2s] + /bin/cat /home/abuild/rpmbuild/SOURCES/0001-fix-compiler-warnings-about-signed-unsigned-int-cons.patch
[    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 constants
[    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?

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.





More information about the Dev mailing list