On Mon, 2014-12-15 at 15:05 +0200, Markus Lehtonen wrote: > On Tue, 2014-12-09 at 16:06 +0200, Markus Lehtonen wrote: > > Hi, > > > > On Wed, 2014-12-03 at 18:53 +0100, Dominig ar Foll (Intel OTC) wrote: > > > Hello, > > > In the proposed wiki page for Tizen Distro Workflow > > > https://wiki.tizen.org/wiki/Tizen-Distro_Workflow > > > > > > I would like to open the discussion on the specific issue of maintaining > > > Tizen evolution and resynchronisation with newer release of Yocto. > > > > > > 1) Source code sync seems covered > > > ----------------------------------------------- > > > My reading is that for the majority of our work which is modifying code, > > > the process covers the need. > > > The code would be changed in git which is reviewed in gerrit and > > > triggers a test build in a Yocto buildbot and then a build in an OBS. > > > Code is unique but shared by the two build systems. > > > > > > "only tricky" cases will be induced by code which will build on one > > > subsystem and not on the other. > > > So far, I am happy to assume that is will be rare. > > > > > > 2) A change is required in the Meta-data > > > ---------------------------------------------------- > > > For any reason a change is required in the building meta data, new > > > dependency, special case to support and architecture, ... > > > In reality those changes are not frequent but do occurs. > > > > > > I would like to better understand your proposition. Could you please > > > confirm or reject my understanding and explain better what is your > > > proposition if you feel that I missed the point. > > > > > > A) The developer should do a modification on the Yocto side (bb files/ > > > layers) as the OBS side (spec) are generated automatically from the bb > > > files/layers. > > > > The proposal would allow for packages to not have automatic > > conversion from bb to spec. Allow developers to maintain the > > the packaging information in .spec for a transition period. > > At some point, automatic conversion would be used for all > > packages. > > > > In the other thread with Patrick we had discussion about this. > > Periodic check/sync of the packaging metadata of these packages > > would be needed for the transition period. > > > > > > > B) Should the developer always create a bbappend file to contain his > > > changes or can he patch the bb files directly. > > > Note the later is far easier for him but make the realignment with the > > > next revision of Yocto would be become more complex. > > > Could you explain your vision on the process when a realignment with > > > Yocto will be required. > > > > All Tizen-specific modifications would be in Tizen-specic layer > > in tizen-distro. IMO, using bbappends would be the (strongly) > > suggested way to modify oe-core packages. Bb files only to be > > used if absolutely necessary. > > > > Re-alignment with oe-core (or any other "upstream" layers) would be > > something like: > > 0. In a staging environment... > > 1. Pull patches from upstream layers > > 2. Find orphan bbappend files (i.e. for the cases oe-core has done > > version bump but Tizen's bb points to the old version) > > 3. Rebase orphan bbappend files > > 4. Run test build and fix problems > > 5. When happy, merge the changes. > > > > This wouldn't be automatic, but done in controlled manner by the > > distro maintainers. > > > > > > > C) In your proposal, the bb files would be associate to each package in > > > Tizen what is different from the traditional Yocto unified model. > > > How the developer will have a view of all the meta data affecting his > > > package in order to propose a change from that reduced vision ? > > > > I think that in order to effectively work with the .bb metadata > > the developer needs to use the tizen-distro combined repository. > > > > There will be a helper tool (supposedly git-buildpackage) that > > helps working with the tizen-distro and per-pkg repositories. > > Good that you brought this up because I need to add a proposal > > of the helper tool to the wiki, too. > > I added a new wiki page to describe the developer's view, the > git-buildpackage tool and the per-package repository content: > https://wiki.tizen.org/wiki/Tizen-Distro_Developer_Workflow#Non-native_packages
Some comments on that page. In "gbp clone-bb", you mention checking out a branch like "meta". Can you elaborate further on that? Why not use the "tizen" branch like before? Regarding the content of the per-package repos: I vote for storing the bb meta data in "meta-tizen" and only support it there. It feels cleaner than mixing it with .spec meta data and simplifies change tracking, because "git log meta-tizen" will not include the automatically updated .spec files. The big unsolved problem is indeed referring to the source code. A .bbappend file must not only add a reference to the Tizen git tree, it must also remove the one from the underlying .bb file. What that is depends on the .bb file and can change over time. The per-package .bbappend (or .bb) can refer to the full git tree with the right branch and tag. For example, openssh_%.bbapped could look like this: SRC_URI_remove = "ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-6.6p1.tar.gz"; SRC_URI_prepend = "git://review.tizen.org/gerrit/platform/upstream/openssh;branch=upstream;protocol=ssh;rev=upstream" Some caveats: * The git fetcher is told to use ssh, so each developer has to configure that to work with review.tizen.org. Using anonymous HTTPS is not an option because review.tizen.org then asks for username/password via HTTP. * rev in the merged repositories needs to be replaced with a git commit hash. Using a tag or branch name implies that bitbake needs to access the network each time it starts, to determine what the actual source code is. That would be slow. I suggest to keep the string above as-is in the individual trees and only replace it when accepting a submission. * "gbp build-bb" is even more complicated. It should not reference review.tizen.org because that would imply fetching the git tree again. Perhaps remove the protocol and replace the URL with the local path? "gbp build-bb" does not rely on changes actually being committed to git, does it? I'd expect it to add uncommitted source code changes as additional patch and use the modified .bb[append] files. Perhaps an --include-all option as in gbs would be useful. Minor nitpick for the example .bb[append] files: they should have a SECTION matching Tizen guidelines (https://wiki.tizen.org/wiki/Packaging/Guidelines#Group_Tag). It's not relevant for the workflow; it's just for the sake of completeness. About non-native packages with joint packaging model you mention that "These commits [which are are already found in oe-core] need to be marked with a special "Pq-Bb: Ignore" meta tag in the Git commit message." This will not be possible without rewriting the history of the "tizen" branch. I wonder whether it wouldn't be simpler at that point to switch to the cleaner orphaned packaging mode. In other words, don't support this "Pq-Bb: Ignore" special case. Regarding test cases: you can find some .bbappend files for existing packages in meta-tizen, for example https://review.tizen.org/gerrit/gitweb?p=scm/bb/meta-tizen.git;a=blob;f=meta-tizen-adaptation/meta/recipes-multimedia/alsa/alsa-utils_%25.bbappend;h=a5db1d7a9c263d5dd7fef5d30338c7b7503818f1;hb=refs/heads/tizen alsa-utils.bb has some patches. So that covers a not too trivial "non-native in orphaned packaging mode" example. Another one with patches in the .bbappend is https://review.tizen.org/gerrit/gitweb?p=scm/bb/meta-tizen.git;a=blob;f=meta-tizen-adaptation/meta/recipes-support/sqlite/sqlite3_%25.bbappend;h=adedafc8629be1661c6964bb200b876cdba23edd;hb=refs/heads/tizen There's no readily available example for "non-native + joint packaging", but it wouldn't be hard to turn one of those into that. Native meta data currently only exists from the spec2yocto tool, for example: https://review.tizen.org/gerrit/gitweb?p=scm/bb/meta-tizen.git;a=tree;f=meta-tizen-common-base/recipes-support/adns;h=2c930eff76f01a4cea24d1dcaffa75b8c6c23dfd;hb=refs/heads/tizen -- 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. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
