On Fri, 2014-11-28 at 10:10 +0200, Markus Lehtonen wrote: > Hi, > > Thanks for your comments. > > On 27/11/14 15:33, "Patrick Ohly" <patrick.o...@intel.com> wrote: > > >On Wed, 2014-11-26 at 16:02 +0100, Dominig ar Foll (Intel OTC) wrote: > >> The infra team has taken the time to document a model proposition and > >> would like to get all the feedback possible. > >> https://wiki.tizen.org/wiki/Tizen-Distro_Workflow > > > >Before diving more into it, let's clarify some points: > > > >What does "the above automation" refer to in the last section? Just the > >"Syncing of external repositories" or everything? > > Ah yes. It refers to the syncing of external repositories, e.g. oe-core. > > > >In the "RPM vs. BitBake packaging meta data" section, can you clarify > >which meta data can be edited manually? It just says "packaging updated" > >and it does not become clear which one that is. But as the flow diagram > >always ends up modifying the .spec file, I assume that only the .bb data > >may be edited. What happens when a change gets committed with > >modified .spec? > > There would be a distinction between "fully automatically maintained" spec > files and "semi-automatically" maintained spec files.
Which spec files will be "semi-automatically" maintained? I wasn't aware that we had such a category ;-} What we will have is a) package meta data maintained as .bb (either from Yocto or in Tizen) and .spec file generated from that and b) package meta data maintained as .spec. I can see how https://wiki.tizen.org/wiki/File:Tizen-distro-spec-autoupdate.png will work for case a), except that the "semi-automatically" maintained check seems redundant. I also have some more comments below. But what about case b)? Do we want to integrate spec2yocto into the new workflow? I'd say no, we shouldn't do that. It has this known limitation of producing .bb files which don't work on all target configurations. Integrating it would make the workflow even more complex. What we can do is the current "Tizen on Yocto" approach of occasionally converting some .spec files into meta-tizen. The obvious downside is that meta-tizen lacks Tizen and most likely will never be quite complete. It will be much better to maintain all packages with .bb, Regarding .bb -> .spec: how does the .bb file refer to the source code that it compiles? This is relevant for the flow where only source code got modified in a commit. The recommended approach for traditional Yocto layers is to refer to a specific source archive or a fixed revision in a source control system like git, because using a varying reference to a source control system (like "current master") has the downside that each build must check these systems for changes, thus slowing down a build even when nothing changed. How will that be handled in the per-project git tree? -- 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 Dev@lists.tizen.org https://lists.tizen.org/listinfo/dev
