On 28/11/14 14:17, "Patrick Ohly" <[email protected]> wrote: >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" <[email protected]> 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 ;-}
It's the "spec file marked for auto-update" in the diagram. Need to make the description clearer on this. >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? Well, I wouldn't like to see spec2yocto. I'd like to see push towards maintaining all packaging metadata as .bb. The idea behind the auto-generation of .spec-related patches for the "semi-automatic" packages was to work as a gentle push/reminder towards maintaining the packaging metadata in .bb. That could be removed, if seen useless/redundant/annoying. >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. Yes, I agree. Something like the "occasional sync" solution you suggested would probably be doable, e.g.: 1. Convert all "semi-automatic" packages from .bb -> .spec 2. For every package that there is delta, convert back from .spec -> .bb and push patch for review. >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, Yup. But we might need to do something like that under a transition period where all maintainers are not yet using .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? In a similar way than in Yocto: the .bb file refers to certain upstream commit or version number. For "joint packaging" model (most if not all packages in Tizen, currently) where source code and packaging are on the same branch the patches will be generated and .bb auto-updated at the time when the files are exported from the per-pkg repo to the meta-tizen layer. Somewhat similar to what gbs export does. For "orphan packaging" model the patches are in the git tree so export is simply just a copy operation. Tizen native packages would need to have reference to the tizen Git repository (i.e. "itself") and have SRCREV=HEAD. The SRCREV will be then auto-replaced when the package gets exported to meta-tizen. Thanks, Markus --------------------------------------------------------------------- Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
