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 I'm will add references a prototype implementation of git-buildpackage-bb soon. [..SNIP..] > > Thanks in advance for your clarifications. > > > > Thanks for your questions. I hope my answer shed some light over the > subject. Obviously, there still are murky and unresolved questions > and the whole setup is complex. I will update the wiki page based > on the comments from you and Patrick. I made updates to the wiki page. Mainly regarding automatic rpm metadata generation under "RPM vs. BitBake packaging meta data" and manual synchronization under "Syncing of external repositories". Thanks, Markus _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
